Date: Fri, 8 Mar 2002 00:08:49 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Nate Williams <nate@yogotech.com> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, arch@FreeBSD.ORG Subject: Re: Contemplating THIS change to signals. (fwd) Message-ID: <Pine.BSF.4.21.0203072354560.46841-100000@InterJet.elischer.org> In-Reply-To: <15496.22850.811384.136422@caddis.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 7 Mar 2002, Nate Williams wrote: We're talking about a STOP received while (or before) the syscall blocks in a sleep(). > > SIGSTOP doesn't interrupt the system call. > > Sure it does. The system call does one of two things. > > 1) Prematurely exits, but allows itself to be re-started automatically > upon reciept of SIGCONT No, it is not really interrupted. It has not been sent back to the userland. A STOP certainly doesn't prematurely kill it. Its stack still says that it is in the sleep. If the SIGCONT occurs, it is still in the sleep where it was before an if not, the timeout timer is still running.. An interrupted sleep is when the timeout is cancelled and control is returned so that it goes back towards the userland. This does not happen in a syscall when a SIGSTOP is received. > *or* > 2) Completes, but has a return value such that the userland program can > re-start the system call again. This is never the result of a STOP signal detected in msleep(tsleep) > > In both cases, it has been 'interrupted' (it did not complete as it > would had it not received a SIGSTOP signal). SIGSTOP does not do this (unless you have set a signal handler for it in which ccase it is no longer SIGSTOP but rather something else (in fact CAN you set a SIGSTOP handler?) > > > it moves if from the temporary (maybe) sleep to a permanent (until > > CONT arrives) SUSPENDED state, but never interrupts it. > > Now we're arguing semantics. We must allow the program the ability to > return control back to the userland, and not stay in the kernel. SIGSTOP doesn't do that. > > > > > > > On Thu, 7 Mar 2002, Nate Williams wrote: > > > > > > > > My suggestion is to stop making STOP type signals an exception, > > > > > > because it should not be necessary to stop them in the middle of a > > > > > > syscall, just stop them from getting back to userspace. > > > > > > > > > > What about when you suspend a process in the middle of read/write, which > > > > > are syscalls? This kind of behavior is *extremely* common-place. > > > > > > > > > > > > The question, is, can you tell the difference between the case where > > > > the proces is suspended at the user boundary and where > > > > the process is doing it's sleep? > > > > > > How are you going to 'interrupt' the system call without interrupting > > > the system call? Maybe I'm misunderstanding, but it sounds like you > > > are proposing that no system calls need to be interruptable. > > > > > > > > > Nate > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0203072354560.46841-100000>