Date: Thu, 7 Mar 2002 23:25:06 -0700 From: Nate Williams <nate@yogotech.com> To: Julian Elischer <julian@elischer.org> Cc: Nate Williams <nate@yogotech.com>, Poul-Henning Kamp <phk@critter.freebsd.dk>, arch@FreeBSD.ORG Subject: Re: Contemplating THIS change to signals. (fwd) Message-ID: <15496.22850.811384.136422@caddis.yogotech.com> In-Reply-To: <Pine.BSF.4.21.0203072207030.46043-100000@InterJet.elischer.org> References: <15496.14346.988827.915384@caddis.yogotech.com> <Pine.BSF.4.21.0203072207030.46043-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 *or* 2) Completes, but has a return value such that the userland program can re-start the system call again. In both cases, it has been 'interrupted' (it did not complete as it would had it not received a SIGSTOP signal). > 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. > > > 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?15496.22850.811384.136422>