Re: more mainloops in more threads?

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?


- -- 
+--- -- -                                                 --  ----+
|   Roberto -MadBob- Guido ---+--- bob4mail[AT]          |
|                             +--- madbob[AT]      .
.                             |
    Step #1 in programming:   +---    |
|      understand people      +---         |
|                             +---         |
+--- ---- -                                              -- -  ---+
Version: GnuPG v1.4.6 (GNU/Linux)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]