Re: About GtkThread.sync, GtkThread.async and where do the GUI events live
"Stalkern 2 (Fastweb)" <[email protected]> Sat, 07 Feb 2009 14:21:38 +0100
| Newsgroups | gmane.comp.lang.ocaml.lib.gtk |
|---|---|
| Message-ID | <[email protected]> |
Stalkern 2 (Fastweb) wrote: > Stalkern 2 (Fastweb) wrote: >> Hello to everybody! >> [...] > I see that the label of the button committed for destruction is no > longer modified: > _either this does not happen because it is GtkThread.async requesting > the modification and so things are postponed indefinitely (but why does > the button react normally to GtkThread.sync then?) > _or the button is SIMPLY not destroyed at all, because GtkThread.async > is postponed indefinitely (but why does the button disappear then?) > > In the latter case, it seems to me that the use of GtkThread.sync and > GtkThread.async is not enough; a timeout must be added. > Am I right? Probably my little test example was rather about garbage collection, than threads :-(. I see that having an example of conflict between threads, leading to failure in short time when not using GtkThread.sync and GtkThread.async, is probably a work on its own. Anyway I've been re-reading the previous posts on lablgtk and threads and I think that I understand that the use of GtkThread.sync and GtkThread.async would be *enough* for *always* avoiding collisions, and the insertion of timeouts is a second choice, because it works in practice but has no reason to work always. I hope that I'm correct... Ernesto