lkml.org 
[lkml]   [1999]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: SIGCONT misbehaviour in Linux
Date
From


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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.090 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site