From owner-freebsd-arch Thu Mar 7 22:25:27 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id F3B7137B416 for ; Thu, 7 Mar 2002 22:25:15 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id XAA18016; Thu, 7 Mar 2002 23:25:12 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g286P6306706; Thu, 7 Mar 2002 23:25:07 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15496.22850.811384.136422@caddis.yogotech.com> Date: Thu, 7 Mar 2002 23:25:06 -0700 To: Julian Elischer Cc: Nate Williams , Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: Contemplating THIS change to signals. (fwd) In-Reply-To: References: <15496.14346.988827.915384@caddis.yogotech.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > 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