>>>>> On Thu, 10 Aug 2006 13:17:03 +0200, Jan Djärv <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
_______________________________________________
emacs-pretest-bug mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
