Date: Thu, 7 Mar 2002 18:14:31 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Terry Lambert <tlambert2@mindspring.com> 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: <Pine.BSF.4.21.0203071800220.37321-100000@InterJet.elischer.org> In-Reply-To: <3C880F87.62D81504@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0203071800220.37321-100000>