Re: more mainloops in more threads?

["Tristan Van Berkom" <tristan van berkom gmail com>]

On Tue, Apr 1, 2008 at 5:05 PM, Roberto -MadBob- Guido
<bob4mail gmail com> wrote:
> -----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).

LOL, I have to point out, you are using fancy words indeed ! :D

lets see if I can say what I said before in simpler terms, regardless if
the signal was triggered by a gtk+ api, its a GSignal none the less and
when g_signal_emit() is called, all callbacks that will run as a result
are called before g_signal_emit() returns, there is no deffered execution
or anything mystical about it.

I guess what you want is to call apis on your GObject from a separate
thread that handles some IO, when that GObject is accessed from
the IO dedicated thread, the resulting signal emissions will be called
as a result of the access (synchronously and *in the same thread*).

ofcourse, declaring the GObject in one thread doesnt mean you cant
access it from another, it is just data, and its functions will execute
in the thread you call them from.

>  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?

Basically yes, the GMainContext is the owner of its own GSources.
one (or more, recursive) mainloop(s) can be run per GMainContext.

You need to have one for each thread that you run a mainloop in,
to keep track of what GSources go in that thread.

Note, I cant speak for the original "purpose" or history of this
data structure.

-Tristan