Date: Thu, 07 Mar 2002 17:10:31 -0800 From: Terry Lambert <tlambert2@mindspring.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: <3C880F87.62D81504@mindspring.com> References: <Pine.BSF.4.21.0203071600290.37321-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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... 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. 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. -- Terry 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?3C880F87.62D81504>