From owner-freebsd-arch Fri Mar 8 12:20:21 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 0AA6637B405 for ; Fri, 8 Mar 2002 12:20:11 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020308202010.DDVW1214.rwcrmhc54.attbi.com@InterJet.elischer.org>; Fri, 8 Mar 2002 20:20:10 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA49764; Fri, 8 Mar 2002 12:01:09 -0800 (PST) Date: Fri, 8 Mar 2002 12:01:08 -0800 (PST) From: Julian Elischer To: Nate Williams Cc: Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: Contemplating THIS change to signals. (fwd) In-Reply-To: <15496.58430.16748.970354@caddis.yogotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Fri, 8 Mar 2002, Nate Williams wrote: > > Except for read() or recvfrom() system calls, and potentially things > like 'sendfile()'. Also, write() may behave differently (since write > involve disk writing, not network writing). I don't actually see how read()/recv() acts differently. > > Userland context? where does userland context come into it? > > Sorry, I meant 'kernel context' above. My bad. I'll repeat. > > I'm still not getting a warm fuzzy that allowing the kernel context to > complete and then block at the userland boundary is a good idea. I'm > not saying it's a bad idea, but I'm almost positive there are gremlins > hiding in the details here. :) Me too but I can't find the little devil. That's why I'm asking everyone here.. > > I know, but prior to this change, it moved to the STOPPED queue, and > then back to the SLEEP queue upon receipt of SIGSTOP and SIGCONT > signals. there is no STOPPED queue. STOPPED processes are on no queue. they assume that teh parent knows they are there and will restart them. (hmmmm) > > No it doesn't stop it everywhere. if you have not set PCATCH or if you > > do not sleep you will proceed forwards oblivious of the pending signal, > > until you try return to user land, at which point you will be stopped, > > just as I am suggesting, except I am sugesting that we should ALWAYS > > stop it there. > > I'm assuming we're talking about processes with PCATCH set, since that's > the behavior that will change. But, thanks for clarifying. > Then we have the potential for race issues, since it could be possible > for one thread to get a SIGSTOP, and another to get a SIGCONT very soon > after, so we must guarantee that the order these are received is done > correctly. Doing this 'safely' almost always involves locking. there is a PROC_LOCK(p) in that part of the code anyhow.. so we might as well do it there (at the user boundary). > > > > Nate > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message