DragonFly commits List (threaded) for 2007-02
Re: 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 ...
On Sunday 14 January 2007 09:59, Matthew Dillon wrote:
> 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
> 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?