DragonFly BSD
DragonFly kernel List (threaded) for 2005-05
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

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 ...

From: David Xu <davidxu@xxxxxxxxxxx>
Date: Sat, 14 May 2005 07:22:34 +0800

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?

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

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]