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

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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?
:
:Aggelos

    If you specify the same mailbox address for different signal numbers,
    then the signals can overwrite each other.  The user program would then
    only be able to tell that one (or both) of those signals occured, but 
    not exactly which one (or both).  Normally this would not be a problem
    since the user program would only use the same mailbox if it intended
    to do event checking related to both signals based on that mailbox.

    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
    }



					-Matt
					Matthew Dillon 
					<dillon@backplane.com>