Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles; site ea.UUCP
Path: utzoo!watmath!clyde!akgua!mcnc!decvax!harpo!ihnp4!inuxc!pur-ee!uiucdcs!ea!mwm
From: mwm@ea.UUCP
Newsgroups: net.unix-wizards
Subject: Re: 4.2 progressive or dead end - (nf)
Message-ID: <13500014@ea.UUCP>
Date: Thu, 19-Apr-84 16:40:00 EST
Article-I.D.: ea.13500014
Posted: Thu Apr 19 16:40:00 1984
Date-Received: Sun, 22-Apr-84 09:21:05 EST
References: <34@sask.UUCP>
Lines: 26
Nf-ID: #R:sask:-3400:ea:13500014:000:1003
Nf-From: ea!mwm    Apr 19 15:40:00 1984

#R:sask:-3400:ea:13500014:000:1003
ea!mwm    Apr 19 15:40:00 1984

/***** ea:net.unix-wizar / idis!dan /  8:07 am  Apr 16, 1984 */
The "brouhaha about signals in 4.2BSD" is not unwarranted.
The interruption of a system call by a signal was useful behavior
for which 4.2bsd provides no good substitute.  It is damn near
impossible to simulate the old behavior and the only other way
to avoid restarting a system call is to (yecchh) longjump.

				Dan Strick
				[decvax|mcnc]!idis!dan
/* ---------- */

Partially false. The only case I can think of where you actually want a
system call interrupted (as opposed to continuing cleanly) is read/write.
For those, select(2) does almost exactly what you want. Occasionally, it'll
even be closer than read/write. It is ugly as sin, but that's a small price
to pay for not having to worry about whether or not I was in a system call
when the signal came.

I prefer the way berkeley did it. If only they'd done a thorough job of it,
and gotten *all* the gotchas out of the signal mechanism, instead of just
most of them.

	<mike