Re: Lockup

[Jan Djärv]

YAMAMOTO Mitsuharu skrev:
> > > > > > On Thu, 10 Aug 2006 13:17:03 +0200, Jan Djärv <address@hidden> said:
>
> > > My intention was that the above scenario would be avoided with
> > > BLOCK_INPUT around functions that may call malloc-related
> > > functions.
>
> > It does not help if the calling thread is one of the Gnoem threads.
>
> But a signal delivered to a non-main thread is redirected to the main
> thread by SIGNAL_THREAD_CHECK.

A signal yes, but I was thinking of this scenario:

A Gnome thread does malloc, gets the mutex lock and enters the malloc code.
A signal is delivered (in the main thread as you point out) and enters malloc 
also.  This situation is exactly like the one with the lockup, but here we 
can't use BLOCK_INPUT around the malloc related functions because they are in 
the Gnome code.

> > > How about just changing the order of lock/unlock and
> > > BLOCK_INPUT/UNBLOCK_INPUT in the previous version of
> > > BLOCK_INPUT_ALLOC/UNBLOCK_INPUT_ALLOC?
>
> > That would mean that lock/unlock mutex functions are called in the
> > signal handler context, which is not allowed according to the
> > documentation.
>
> Yes, pthread_mutex_(un)lock is not async-signal-safe.  But we are
> already using such functions as malloc in the signal handler context
> (with the help of BLOCK_INPUT).  I guess calling
> pthread_mutex_(un)lock in the signal handler context is safe in
> reality unless the interrupted thread is also executing
> pthread_mutex_(un)lock for the same mutex.  I think it's better than
> the current one, i.e., not protecting shared resources such as
> __malloc_hook in the signal handler context.

I agree with your assumtion that the lockuo occurs because the signal handler 
and the interrupted therad are calling pthread_mutex_(un)lock for the same 
mutex.  But BLOCK_INPUT does not help, because Gnome code does not have it.

So I tried to do the next best thing, i.e. block SIGIO in non-main threads. 
The problem with this is that I can't block SIGIO before taking the mutex, 
because if I hang when taking the mutex, SIGIO would remain blocked.  One 
could use trylock and some sort of busy loop, but I don't think that is usable.

> (Of course SYNC_INPUT is the right direction, but the current plan is
> not enabling it in the next release as far as I understand.)

Unless someone comes up with a supersafe scheme I think we have to live with 
this race condition until then.  But it is better now than before, SIGIO and 
the main thread executing the sam (un)lock should not lockup.  But if the 
signal handler is executing in one thread one one processor and a Gnome thread 
is executing on another processor, there could be a lockup.

        Jan D.