>>>>> On Fri, 11 Aug 2006 09:04:34 +0200, David Kastrup <[EMAIL PROTECTED]> >>>>> said:
> YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] _______________________________________________ emacs-pretest-bug mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
