Date: Thu, 7 Mar 2002 22: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.0203072207030.46043-100000@InterJet.elischer.org> In-Reply-To: <15496.14346.988827.915384@caddis.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
SIGSTOP doesn't interrupt the system call. it behaves differently. it moves if from the temporary (maybe) sleep to a permanent (until CONT arrives) SUSPENDED state, but never interrupts it. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0203072207030.46043-100000>