[no subject]

> - GStaticMutex is used instead of GMutex. This makes it possible to
>   initialize a GMainContext before calling g_thread_init ();

Didn't we say that g_thread_init() _must_ be called before any
other GLib functions. Using a GStaticMutext for this reason
strikes me as a bit dubious...

> - Adapted and Extended tests/mainloop-test to new setup. Works ok here.
>   The failures in the old versions seems to be caused by incorrect
>   locking. I now use one big lock instead of the two before and now it
>   works like a charm.

Hmm, I'd rather know _what_ the incorrect locking was. Maybe I'll
take another look at it later.

> All in all I like this patch very much.... ;-) and I hope you do as well.
> Really this patch (at least the API, I proposed) really would make life for
> ORBit/ORBit-mt much easier.

Hmm, well, as you can see above, I don't _completely_ like
it. :-) 

Your proposed changes to the interface certainly clean it up some,
but I'm worried that the result behaves in unexpected ways.

We basically have two courses we could take:

 * Try and figure out how to implement your interface so that
   multiple threads can actually iterate the same thread. 

   This probably is the ideally preferrable course, but it has
   always struck me as very hard, and the resulting behavior
   might still be confusing.

 * Try and achieve your initial goals:

   - Creating a context before the thread
   - Iterating multiple contexts from a thread

   In a simpler way. For instance, say that a context can only be
   iterated from a single thread, but allow a context to
   explicitely be moved between threads when it is not being
   iterated.

> Another thing, that really makes me wonder are the lines 
>  
>   'if (pollrec->fd->events)'
> 
> in g_main_context_qurey and g_main_context_check. Can't this be checked in
> g_main_context_add_poll, or do we allow fd's with empty event fields to be
> added. Actually this would indicate a programming mistake, doesn't it? 

I think it is mainly a case of allowing all cases, including the
NULL one for the sake of completeness. I'm not sure a 0 field
here is actually a programming mistake... it could occur
theoretically through simple laziness.

Regards,
                                        Owen