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