Re: more mainloops in more threads?
- From: Roberto -MadBob- Guido <bob4mail gmail com>
- To: gtk-list gnome org
- Subject: Re: more mainloops in more threads?
- Date: Tue, 1 Apr 2008 22:05:18 +0200
-----BEGIN PGP SIGNED MESSAGE-----
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
, 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?
+--- -- - -- ----+
| 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)
-----END PGP SIGNATURE-----
] [Thread Prev