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

[Victor Balada Diaz <victor@xxxxxxxxx>]

On Sat, Jan 13, 2007 at 11:59:09PM -0800, Matthew Dillon wrote:
> dillon      2007/01/13 23:59:09 PST
> 
> DragonFly src repository
> 
>   Modified files:
>     sys/kern             kern_sig.c kern_synch.c 
>     sys/machine/pc32/i386 machdep.c 
>     sys/machine/vkernel/i386 cpu_regs.c fork_tramp.s trap.c 
>     sys/machine/vkernel/include globaldata.h md_var.h 
>     sys/machine/vkernel/platform systimer.c 
>     sys/sys              proc.h signal.h signalvar.h 
>     sys/vm               vm_vmspace.c 
>   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.

What happens if a second signal gets delivered to the process before
the first signal is checked by the userland process?

-- 
La prueba más fehaciente de que existe vida inteligente en otros
planetas, es que no han intentado contactar con nosotros.