I agree. If you look at the description of EINTR, that is quite clear.
[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 :-)
|> Notice that SIGTSTP, SIGTTIN and SIGTTOU should be handled at the same
|> place when the default signal behaviour is applied, as well as some other
Agreed.
|> 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.
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/