cvs commit: src/sys/i386/include tls.h src/gnu/usr.bin/cc34/cc_prep/config dragonfly-spec.h src/gnu/usr.bin/cc34/cc_prep/config/i386 dragonfly.h src/lib/csu/i386 crt1.c src/lib/libc/gen tls.c src/lib/libc/i386/sys cerror.S src/lib/libc/include libc_private.h ...

[David Xu]

Joerg Sonnenberger wrote:
On Fri, May 13, 2005 at 10:11:52PM +0800, David Xu wrote:

Process does not have global signal mask, it is each thread in a process
has its own signal mask. there is a global pending signal set in the 
process.Each thread has its own pending set, signal masks, but share 
signal action with other threads


So far, I understand. Question is, when the kernel decides to deliver
a signal to thread A, which doesn't have it currently in the signal
mask, it adds the signal to the thread signal masks, removes the pending
bit and calls the handler. Now the same signal is send to the application
again. Is thread B allowed to handle that signal while thread A is still
running in the signal handler?
Joerg
Yes, there is no reason why it shouldn't, concurrently handling
signal is allowed.
There is also a SA_NODEFER flag for sigaction syscall, same thread
does not block the signal when the signal is delivered to user code,
although I don't know which application actually needs this feature.
David Xu