-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 01 April 2008 20:47:25 Tristan Van Berkom wrote: > A GObject is in your programs data, your threads share the same > data - signal emmissions are a synchronous affair, no weird surprises, > when a gtk+ api is called, all related signal callbacks are executed > *before* the gtk+ api in question returns. > My dubts are not strictly related to GTK+ (so, perhaps this is not the most correct list where to expose: there are any more connected to Glib?), but management of different GObjects "branches" into the same application. An example: currectly I'd like to build a list of callbacks connected to a well specified object emitting signals when events occour on the filesystem [1], and those signals would be handled with no matter about others parts of the application. I am concerned about overhead introduced by management of this dedicated object (and dedicated signals dispatching), so I am looking for ways to isolate the loop and execute it on a contained environment (gaining from true parallel computation granted from multicore architecture). Perhaps my preoccupations are due my bad understanding of signal dispatching internals, and the addiction of a object to monitor and for which dispatch signals do not introduce overheads on scheduling: any comment on it, or demystifing readings about? Just to remain in theme: what's the current purpose of GMainContext? Only to abstract handling of multiple GSources? 1: http://lobotomy.sourceforge.net/docs/tech/libhyppo-0.3rc2-public/group__hyppovfsset.html - -- +--- -- - -- ----+ | Roberto -MadBob- Guido ---+--- bob4mail[AT]gmail.com | | +--- madbob[AT]jabber.linux.it . . | Step #1 in programming: +--- http://madbob.homelinux.com | | understand people +--- http://lobotomy.sf.net | | +--- http://barberaware.org | +--- ---- - -- - ---+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH8pWD3wUck/os3BkRAqAKAJ92gntb9c4smww0IIiV4cb2Mrx1/QCfT+xJ 1BH6a9/3pZBmueFgA7WM+XY= =edYb -----END PGP SIGNATURE----- _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list