Re: nasty bug in multithreaded g_main_loop...

[Sebastian Wilhelmi <wilhelmi ira uka de>]

Hi, Owen

> OK, there is an easy fix for this one. We can just split the
> main_loop lock into two pieces - one for the poll array and
> one for the rest. Could you try the following patch out?

This seems to work now, many thanks to Tim.
 
> There are two more general points, though brought up
> by this:
> 
> a) Should we have recursive mutexes? We decided against
>    this initially because we didn't seem to need them
>    and there were a number of portability problems.

I still would not like to have them at this point.
 
>    (They aren't available for all pthreads implementations
>    in a standard way, and so you need to emulate them, and
>    if you emulate them, then you run into the problem
>    that all threading systms don't have a nice equivalent
>    of pthread_self() so you might have to emulate that too...)

I would say, that every thread system has something like pthread_self()
actually. It might not always be a `small int', but I think, it'll always
be at most a pointer.

>    I'd tend to stick to this opinion; less because I'm
>    worried about changing this API (which few people
>    are using yet), than because the original reasons
>    for avoiding them still hold.
> 
>    (In my opinion, recursive mutexes are poor practice
>    because they indiciate you don't know where your
>    locks are being held, which leaves you vulnerable
>    to other types of deadlocks. But they are occasionally
>    useful.)

That of course depends. I think, it's not that easy to say that, from a
certain complexity (which already seems to be reached by glib) it's hard
to say, if you need to reenter a mutex or not, so for later it might be
good to add them, but with some restrictions:

1. They'll not be like the StaticMutexes, but like the Mutexes (I.e. you
have to allocate them etc.)

2. They can't be used in conjunction with conditions. That is, because
recursive mutexes are working different form mutexes is that, while
waiting for a condition you have to backup and reset the entry count. etc.
 
> b) We destroy sources within the main loop lock. This
>    is nasty because we will end up calling the destroy
>    notifies for the user data within the main lock
>    too.
> 
>    So, considering how that destroy-notify is used
>    in many language bindings (reference counting)
>    you could easily end up with the destructor for
>    some Perl object (for example) being called within
>    the main loop lock.
> 
>    And by that time, expecting the application programmer
>    to understand the consequences is a pretty slim
>    chance. (Note that making the main loop lock recursive
>    does not remove all possible problems here)
> 
>    But avoiding this is not easy, since you first
>    have to disentagle the GHook out of the GHookList,
>    unlock, then destroy the hook. This definitely
>    would require modifications to the GHook API's.
> 
>    (Hmmm, I suppose the cheat is to do all destroy
>    notifications from an idle function... (not really
>    a serious suggestion))

So, your looking for some Java-like finalize() fun ;-)

Bye,
Sebastian

-- 
Sebastian Wilhelmi                   |            här ovanför alla molnen
mailto:wilhelmi@ira.uka.de           |      är himmlen så förunerligt blå
http://goethe.ira.uka.de/~wilhelmi   |