On Mon, Dec 30, 2002 at 02:39:00PM +0200, Bill Sommerfeld wrote:
> 
> Module Name:	src
> Committed By:	sommerfeld
> Date:		Mon Dec 30 12:39:00 UTC 2002
> 
> Modified Files:
> 	src/lib/libc/sys: read.2 write.2
> 
> Log Message:
> In EINTR description, add a crossreference to sigaction(2).
> Put reference to "slow device" back in since filesystem & disk I/O, doesn't get
> EINTR while pipes, sockets, ttys, etc., can.

Is there a definitive list of what is "slow" and what is not? For example,
is NFS slow or not? I would assume "slow" since I have a repeatable case
of dump crapping out because it gets a signal from a peer process before
a write() can actually write any data.

Would a single-speed CD-ROM count as slow or not? How about a hard disk
that has blocks the drive has trouble reading (but eventually, 10 seconds
from now, manages to read)? How about a vnd device? How about a device
that actually implements a networked device whose storage lives on
another machine? (Such devices have been described on this list in the
past year or so.)

What makes a slow device different from a non-slow? Anything? Do slow
devices allow the race condition that causes EINTR errors and non-slow
devices do not have this race condition? In an SMP world?

Is this relying on slow vs non-slow devices a portable practice? If not,
why would NetBSD want to encourage nonportable programming? If it is
portable then why doesn't 1003.1-2001 give this distinction in the read()
description which instead says this:

   [EINTR] The read operation was terminated due to the receipt of
           a signal, and no data was transferred. 

Why would NetBSD want to be so much more specific in this one particular
case than the actual standards document? 

Is there any good way for a programmer to know for sure whether or not
"slow" devices will be used as sources or destinations of data? If not
then why should the man page even bother to mention this distinction?

Why would NetBSD want to have stuff in it's documentation that encourages
the coding of broken programs? "Oh, nobody will EVER make this program
send data to/from a 'slow' device!" ... thus leading to dump failing over
NFS.

NetBSD's sigaction() man page says this:

     Restarting of pending calls is requested by setting the SA_RESTART bit in
     sa_flags.  The affected system calls include open(2), read(2), write(2),
     sendto(2), recvfrom(2), sendmsg(2) and recvmsg(2) on a communications
     channel or a slow device (such as a terminal, but not a regular file) and
     during a wait(2) or ioctl(2).  However, calls that have already committed

Ok, so what's a device? Is it a regular file? (I assume this is
addressed above.)

I can't find the part of NetBSD's sigaction() man page in the 1003.1-2001
description of sigaction(), either. I have not, I'll admit, read through
the entire doc.


Who wants to know how much code is in NetBSD that doesn't handle EINTR
from reads and writes correctly? Let's start at the top: /bin/cat, .....
Does NetBSD want to keep code in use that is provably wrong with race
conditions just because nobody has ever reported having an actual
problem before? Or would NetBSD prefer a sweep to fix all of the broken
programs? Because I'll do the sweep if NetBSD actually wants correct
code. I've already started (how do you think I found /bin/cat, anyway?).


Lastly, what is the correct way to handle EINTR from read or write calls?
Is it to use sigaction to keep it from ever happening, or is it to change
the read and write calls to just go ahead and handle EINTR correctly? How
about if the read and write calls are in a library? Use of sigaction in
a library for this purpose doesn't seem like a very safe thing to do.
FWIW, my preference is for the reads and writes to just deal with EINTR.


Is this really, REALLY so big of a deal that NetBSD MUST keep this mention
of "slow" devices in it's man pages? Really? Why?
-- 
Kevin P. Neal                                http://www.pobox.com/~kpn/
      'Concerns about "rights" and "ownership" of domains are inappropriate.  
 It is appropriate to be concerned about "responsibilities" and "service" 
 to the community.' -- RFC 1591, page 4: March 1994