Message-ID: <498D8AE2.1020604 at fastwebnet.it>
Date: Sat, 07 Feb 2009 14:21:38 +0100
From: "Stalkern 2 (Fastweb)" <stalkern2 at fastwebnet.it>
MIME-Version: 1.0
To: lablgtk at math.nagoya-u.ac.jp
Subject: Re: [Lablgtk] About GtkThread.sync, GtkThread.async and where do
	the GUI events live
References: <498AC372.5000608 at fastwebnet.it> <498B0E05.6060609 at fastwebnet.it>
In-Reply-To: <498B0E05.6060609 at fastwebnet.it>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

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

_______________________________________________
Lablgtk mailing list
Lablgtk@yquem.inria.fr
http://yquem.inria.fr/cgi-bin/mailman/listinfo/lablgtk