Re: Lockup

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 11 Aug 2006 09:04:34 +0200, David Kastrup <address@hidden> said:

> YAMAMOTO Mitsuharu <address@hidden> writes:
>> 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 guess ... safe in reality unless ..."

> Maybe I have been around programmers too long, but I don't find this
> exactly reassuring.

Yeah.  IEEE Std 1003.1 provides a table of async-signal-safe functions
(those can be called safely within a signal handler), and neither
malloc nor pthread_mutex_(un)lock is such functions.

  All functions not in the above table are considered to be unsafe
  with respect to signals. In the presence of signals, all functions
  defined by this volume of IEEE Std 1003.1-2001 shall behave as
  defined when called from or interrupted by a signal-catching
  function, with a single exception: when a signal interrupts an
  unsafe function and the signal-catching function calls an unsafe
  function, the behavior is undefined.

(http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html)

We already have malloc calls in the signal handler context with the
assumption that it is safe to call unless the signal interrupts
malloc-related functions.  So I think it's not that bad to also put
reasonable assumptions to pthread_mutex_(un)lock.

                                     YAMAMOTO Mitsuharu
                                address@hidden