From owner-freebsd-arch Thu Mar 7 18:20:56 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 029EC37B47D for ; Thu, 7 Mar 2002 18:20:09 -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 <20020308022009.FMJG1214.rwcrmhc54.attbi.com@InterJet.elischer.org>; Fri, 8 Mar 2002 02:20:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id SAA45543; Thu, 7 Mar 2002 18:14:32 -0800 (PST) Date: Thu, 7 Mar 2002 18:14:31 -0800 (PST) From: Julian Elischer To: Terry Lambert Cc: Nate Williams , Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: Contemplating THIS change to signals. (fwd) In-Reply-To: <3C880F87.62D81504@mindspring.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 Thu, 7 Mar 2002, Terry Lambert wrote: > Julian Elischer 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. > > > > of course > > 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? (Considering that immediatly after the > > sleep finishes, it's going to abort the syscall and go to the user > > boundary because of the signal). > > Put this way, it's the correct thing to do, if it makes > life easier for the KSE stuff. > > It wasn't clear to me that you were actually aborting the > call, rather than allowing it to run to completion, and > then delivering the signal, at least from your text > description... I don't abort the sleep if it's not interruptable. I just done STOP there if I do get a signal. I am a littel worried about sendfile. That system call is so different from the rest of the world that it may need special handling. If you STOP a process at the moment that is sending a 2MB file out a socket, then the transmission stops and the sleep will abort if SB_NOINR is not set. I can't see where it is set so I suspect that it will abort out and come to the user boundary and then restart, but I haven't proved that yet. In that case it would behave about the same with the change as without it. > > It also wasn't clear to me that the patch did what you say > it does. In particular, I wondered if it did the right > thing in the system call restart case (SA_RESTART in the > sa_flags). It would be real annoying to be almost done > with something, and have to restart it, and it would be > equally annoying to be partially done with a write, and > have it interrupted, leaving the written object in an > indeterminate state. Don't forget that many syscalls handle SA_RESTART so that yuo keep getting more data so that in teh end you can't tell the difference. > > If you can vouch for the SA_RESTART case, and for the case > that Nate contemplated (long running call suspended and > restarted, rather than interrupted), then it passes the > filters I care about. > > Nate probably cares more about the "suspend long call in > the middle, with the intent to resume, but the resume is > interrupted, and never happens" case for things like > sendfile. I think the problem there is that it results > in the state of the connection being indeterminate, so it > is hard or impossible to pick up in the middle in the > restart case, and guarantee that the data sent down the > connection isn't duplicated/omitted. In other words, an > HTTP client in an indeterminate state getting a sendfile > from a server could make it so that the server has to > know to abandon the connection, where with the current > code, it can pick up where it left off. I believe so, but have not yet proved it. > > > -- Terry > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message