Re: 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 <davidxu@xxxxxxxxxxx>]

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