Robert de Vries wrote:
>
> This looks very much like *not* a kernel bug.
It is definitely due to the way the thread library is implemented (and
therefore not a kernel bug). As has been mentioned before, the POSIX
spec says pthread_mutex_lock and pthread_mutex_lock cannot be called
from a signal handler. With LinuxThreads the thread stores some
information in its thread structure when a thread is about to block on a
mutex. When you try to use the mutex in the signal handler, the
information gets overwritten. The thread structure is hosed when you
return from the signal handler.
That is probably why a different thread unlocking the mutex from the
signal handler seems to work (assuming that thread was not blocked at
the time of the signal). However, be aware that POSIX says that if one
thread unlocks a mutex that another thread has locked, the result is
undefined. That is, it may work now because of the way LinuxThreads is
currently implemented, but it is not portable and it may stop working in
the future.
> I have modified the program so that the only thing happening in the
> signal handler is a printf. After that I unlock the the mutex from the
> main thread.
>
> The program crashes.
printf calls pthread_mutex_lock, therefore it is async-signal-unsafe.
Any function that calls pthread_mutex_lock or pthread_mutex_unlock
directly or indirectly is unsafe. Some common functions that use locks
include malloc, free, sprintf, fopen, fread, fwrite, and fprintf. There
really is not much you can do safely in a signal handler. You are
pretty much limited to the library functions and system calls someone
posted earlier.
If you want a threaded program to wait for a set amount of time,
pthread_cond_timedwait is probably much easier. Mixing threads and
signals is asking for trouble.
Bill Dieter.
dieter@dcs.uky.edu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:12 EST