Messages in this thread | | | Subject | Re: SIGCONT misbehaviour in Linux | Date | Thu, 16 Dec 1999 14:04:56 +0100 | From | Eric Paire <> |
| |
> > > 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. > I agree that your idea to transfer the STOP/CONT management in the calling process rather the in the managed process seems good. But, you will have to also transfer from do_signal() in ptrace(), the STOP/CONT management of a traced process (which is similar to STOP/CONT), in order to avoid ptrace to modify the process scheduling (gdb would be intrusive otherwise).
> > 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 ??? >
-Eric +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Eric PAIRE Web : http://www.ri.silicomp.com/~paire | Group SILICOMP - Research Institute Email: eric.paire@ri.silicomp.com | 2, avenue de Vignate Phone: +33 (0) 476 63 48 71 | F-38610 Gieres Fax : +33 (0) 476 51 05 32 | FRANCE
- 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/
| |