Re: SIGCONT misbehaviour in Linux
Eric Paire (paire@ri.silicomp.fr)
Thu, 16 Dec 1999 14:04:56 +0100
>
>
> 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/