Re: Lockup

[YAMAMOTO Mitsuharu]

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

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

(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.)

                                     YAMAMOTO Mitsuharu
                                address@hidden