Re: SIGCONT misbehaviour in Linux

Eric Paire (paire@ri.silicomp.fr)
Wed, 15 Dec 1999 07:35:59 +0100

> Eric Paire wrote:
>
> [snip]
>
> |> 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).

>
> [snip]
>
> |> special cases like ignored SIGCHLD,... Part of this code is currently in
> |> machine-dependent do_signal() function.
>
> |> The advantage of such modification is that a blocking system call will
> |> remain in the actual schedule loop whenever SIGSTOP/SIGTSTP and SIGCONT
> |> are sent to him (thus eliminating the EINTR problem, and being POSIX
> |> compatible). The other advantage is that for a traced process, the SIGSTOP
> |> handling may also be managed in the schedule loop, thus avoiding the side
> |> effect of being awaken by PTRACE_ATTACH/PTRACE_CONTINUE.
>
> 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
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 ???

Best regards,
-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/