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

[Aggelos Economopoulos <aoiko@xxxxxxxxxxxxxx>]

On Monday 12 February 2007 18:46, Matthew Dillon wrote:
> :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?

[...]

>     If I am following the case you are describing, then it shouldn't
> matter. That is, it is ok for a signal to occur twice before userland has a
> chance to process the first one, since at that point userland is already in
> the code path to process events related to the signal:
>
>     if (signalmailbox) {
> 		    <<<------ more signals can occur here
> 	signalmailbox = 0;
> 		    <<<------ but it doesn't matter that they are lost
> 		    <<<------ because we haven't processed the events yet
> 	process_events_related_to_signal();
>     }
>
>     Here is an example of code that would be 'broken':
>
>     if (signalmailbox) {
> 	process_events_related_to_signal();
> 		    <<<------ more signals can occur here
> 	signalmailbox = 0;
> 		    <<<------ XXXX and they would be lost forever. XXXX
>     }

Understood. I was thinking of a 'test, set to zero, pause waiting for event' 
race but in this case if the mailbox was nonzero you won't pause and if it 
was, you will pause without zeroing it first, so you're safe either way. 
Again, that was just me being confused.

Aggelos