Messages in this thread | | | Subject | Re: SIGCONT misbehaviour in Linux | Date | Wed, 15 Dec 99 08:36:52 -0800 | From | Simon Patience <> |
| |
Eric Paire wrote: > > Eric Paire wrote: > > |> IMHO, the SIGSTOP management (which is much simpler than the others since > > |> the signal can never be ignored nor caught) should be taken into account > > |> in the schedule loop, and not in the signal management on syscall return > . > > > > You really don't want job control to be implemented in the scheduler! It > > should be implemented in the joc control code on syscall/trap return. I > > know there isn't such code at the moment but that is why you are seeing the > > problems :-) > > > No. my opinion was to locate only STOP/START management in the scheduling loop > in order to avoid exiting it for being managed very lately (just before > returning in user mode). So that if a process is stopped and then restarted > without any signal handler, then it will remain blocked in the scheduler > (which is transparent for functions that blocks a process).
Why are you trying to do this? I can't see the objection to code just before return to user space that says, if I am stopped, wait for sigcont. As you haven't interrupted the processes you won't get EINTR. You don't have to muck with the scheduler, which is always a tricky thing to do, and everything works wonderfully.
> > I don't see this as an advantage. Stop signals should stop the process from > > advancing in user space. You don't need to do anything to them while they > > are in the kernel. > > > My point is that processes that are stopped and restarted, exit from the > main schduler loop, and prepare themselves for returning EINTR in user space > (which is *not* POSIX-compliant, and make GDB very intrusive), since the
But you don't need to change the scheduler to fix that, just don't send interrupt the process when it gets the STOP signal in the first place. Mark the process as stopped, having SIGSTOP in the pending set is good enough but don't wake the process up. Then in do_signal() you special case STOP signals and wait on a semaphore or something (actually a synchronization/condition variable would be good for this situation but Linux doesn't have them). When someone sends SIGCONT, they clear the STOP signal from the pending set (as today) and then signal the semaphore. No interrupt, no scheduler hack, POSIX compliant, simple.
> current implementation of restart does not force them to return to the > scheduler loop for those in INTERRUPTED state. The idea of managing stop > restart without signal handlers within schedule() is to make a simple > machine-independent modification to correct this signal mishandling. > > Any scheduler guru opinion ???
Simon
Simon Patience Phone: (650) 933-4644 Silicon Graphics, Inc FAX: (650) 962-8404 1600 Amphitheatre Pkwy Email: sp@sgi.com Mountain View, CA 94043-1389
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |