Delivered-To: garrigue at math.nagoya-u.ac.jp Delivered-To: lablgtk at yquem.inria.fr Delivered-To: lablgtk at math.nagoya-u.ac.jp Message-ID: <498B0E05.6060609 at fastwebnet.it> Date: Thu, 05 Feb 2009 17:04:21 +0100 From: "Stalkern 2 (Fastweb)" 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> In-Reply-To: <498AC372.5000608 at fastwebnet.it> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Stalkern 2 (Fastweb) wrote: > Hello to everybody! > > I'm about to work with lablgtk-2.10.1 on a threaded application with > some GUI issues and I want to figure out correctly how does the GUI > manage the GUI events. > > So, I've written a test program with two lasting threads and one > short-lived, that affects the materials for the others: > > ------------------------------------------------------------ > buttonConfusedByThreads_v0.1.ml > ------------------------------------------------------------ > (**************************************************************************) > (* After the buttons.ml example packaged with lablgtk-2.10.1 *) > (* In this sample code three threads attempt to (conf)use an item that > was born in the very GUI thread. > * Will the GUI thread understand all the GUI events going on a GUI Item, > * just because the GUI Item itself is shared between threads? > *) > (* > * launch directly with > * $ lablgtk2 -thread buttonConfusedByThreads_v0.1.ml > * or compile with > * $ ocamlfind ocamlopt -thread -package "lablgtk2 unix threads" > -predicates "init threads" -linkpkg -I +lablgtk2 gtkThread.cmx -o > buttonConfusedByThreads_v0.1.opt buttonConfusedByThreads_v0.1.ml > *) > I must correct something here: according to a previous post (September 18, 2008), the toplevel similar behaving like the compiled version would be $ lablgtk2 -I +threads unix.cma threads.cma gtkThread.cmo The behaviour that I notice is still the same, though. If I modify the file like this: ---------------------------------------------------------------------------- 45,47c45,54 < let () = print_endline ("YES!") in < let _testquery = b#label in < (b#set_label "YES!") --- > let boid = GtkThread.sync(*we need an answer*) (fun () -> b#get_oid) () in > let blabel = GtkThread.sync(*we need an answer*) (fun () -> b#label) () in > let () = > Printf.printf > "I, button %d, say: \"%s\"\n%!" > boid > blabel > in > let () = print_endline ("I'll now say YES!") in > (GtkThread.async (fun () -> b#set_label "YES!") () ) 60,62c67,76 < let () = print_endline ("NO!") in < let _testquery = b#label in < (b#set_label "NO!") --- > let boid = GtkThread.sync(*we need an answer*) (fun () -> b#get_oid) () in > let blabel = GtkThread.sync(*we need an answer*) (fun () -> b#label) () in > let () = > Printf.printf > "I, button %d, say: \"%s\"\n%!" > boid > blabel > in > let () = print_endline ("I'll now say NO!") in > (GtkThread.async (fun () -> b#set_label "NO!") () ) 76c90 < (b#set_label "MAYBE!") --- > (GtkThread.async (fun () -> b#set_label "MAYBE!") () ) 81,83c95,97 < List.iter < (hb#remove) < (hb#all_children) --- > GtkThread.async > (b#coerce#destroy) > () 96a111 > ---------------------------------------------------------------------------- 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? TIA Ernesto _______________________________________________ Lablgtk mailing list Lablgtk@yquem.inria.fr http://yquem.inria.fr/cgi-bin/mailman/listinfo/lablgtk