Re: Changes to the GLib main loop [ GMainLoop ]

[Owen Taylor <otaylor redhat com>]

Sebastian Wilhelmi <wilhelmi ira uka de> writes:

> > > Ok, but that could be optimized away by also telling
> > > g_main_context_iterate, whether it was called from g_main_loop_run or
> > > not only signalling other threads, when it was not run from
> > > g_main_loop_run. For calls not done from g_main_loop_run it would
> > > still need to be called, because of the scenario outlined above (the
> > > thread A and B thingy)
> > 
> > This doesn't work because the thread needs to be woken up to check for
> > loop->is_running, even before the main loop stops running its loop.
> > 
> > (Remember, what I want to be able to do here is use main loop to wait
> > for a modal dialog being closed, whether or not the dialog is being
> > shown from the main thread.)
> 
> Ah, I see, but the solution to this is calling g_cond_broadcast in
> g_main_loop_quit. So I think the following is enough:
> 
> * Make g_main_context_iterate call g_cond_broadcast only when not called 
>   from g_main_loop_run.
> * Make g_main_loop_quit call g_cond_broadcast.

Isn't the right way to express this is "broadcast when releasing
ownership of the context?" 

Other than this, yes this approach works pretty well. (Main problem
is if you have a bunch threads waiting for ownership, they all
wake up and try to get ownership)
 
> Does that sound like it should work.
> 
> > Basically, we need to wait on the condition:
> > 
> >  loop->is_running || loop->context->owner == NULL
> > 
> > Trying to do this without having a conditional variable for _this_
> > condition is going to be really inefficient. I think we indeed
> > need to have a separate (demand created) condition variable for each
> > GMainLoop.
> 
> Yes, but having a condition variable for the loop does also mean, that the
> context (in an iteration) would have to signal all loops for that context.
> That sounds much more inefficient.

I guess your concern is that you replace 1 cond broadcast for N
threads waiting with N cond broadcasts. I'm not sure there is
a big difference in efficiency between these two options.

But actually, for the main loop case, we need only need "wake one"
semantics not "wake all" semantics. Which could be accomplished:

 - By using g_cond_signal() on a single condition variable.

 - By picking one out of a list of condition variables and
   calling signalling that.

Anyways, this is an implementation detail - the 'broadcast on
single cond variable' approach should work for now.

Regards,
                                        Owen