cvs commit: src/sys/kern kern_sig.c kern_synch.c src/sys/machine/pc32/i386 machdep.c src/sys/machine/vkernel/i386 cpu_regs.c fork_tramp.s trap.c src/sys/machine/vkernel/include globaldata.h md_var.h src/sys/machine/vkernel/platform systimer.c ...

Aggelos Economopoulos aoiko at
Sun Feb 11 17:42:54 PST 2007

On Sunday 14 January 2007 09:59, Matthew Dillon wrote:
>   Log:
>   Implement a new signal delivery mechanism, SA_MAILBOX.  If specified the
>   sigaction structure's sa_mailbox pointer (field is unioned with
> sa_handler) points to a location in user memory.  When the signal occurs,
> the location is overwritten with the signal number and the next system call
> made (or the current one running) will return EINTR.  NO SIGNAL STATE IS
> PUSHED, NO SIGNAL VECTOR IS DISPATCHED.  This makes mailbox signaling very
> fast.
>   Userland can interlock against the mailbox simply by polling and clearing
>   the mailbox prior to doing a system call.  The mailbox signal will be
>   properly interlocked against the system call.  Userland does not need to
>   make any other system calls (no sigblock() or sigsetmask() calls) to
>   properly interlock delivery.  The kernel interrupts at most one system
> call per signal delivered via this mechanism, even if the userland does not
> clear the mailbox.

I'm not sure what "interlocked against the system call" means. Does it include 
not losing any signals? If so, what about the following scenario?

The program tests and clears the mailbox prior to doing a system call. Suppose 
that a signal has been sent to the process and a page fault occurs after the 
test and before the clear. trap() runs, successfully deals with the fault 
and, on return to userspace, userret() notices the signal so does a postsig() 
which delivers the signal to the mailbox. Back in userland, the mailbox is 
immediately overwritten and the signal number is lost. The next system call 
will get interrupted but the mailbox will be empty and the program will 
probably get very confused (probably assume it was interrupted by an 
unrelated signal). Does this sound plausible?


More information about the Commits mailing list