I've just noticed I wasn't subscribed to current-users. Bummer.  Fixed.
The list archives are missing the past few days mail. Bummer.

On Mon, Dec 30, 2002 at 11:15:08PM -0500, Bill Sommerfeld wrote:
> > 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? 
> 
> It boils down to whether the implementation of the descriptor (file,
> device driver, etc.,) does interruptable or uninterruptable sleeps
> when it sleeps.

And, as was discussed in the edited out part, NFS looks like a filesystem
but yet doesn't behave like a normal local filesystem. 
 
> > Is this relying on slow vs non-slow devices a portable practice? 
> 
> Historically, as you've discovered, a lot of code depends on this.

Uh, yep. I also offered to fix the NetBSD tree. Since I wasn't subscribed
to current-users and the archives aren't up-to-date, I have no idea if
anyone addressed my offer. 
 
> > 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? 
> 
> Historicaly, there have been two aspects to man pages:
>  - a specification to users.
>  - a specification to implementors.
> 
> Because there is a lot of historic code which depends on filesystem
> I/O never returning EINTR, we should move cautiously, if at all, with
> respect to weakening this.

Oops. It's already weakened by NFS. 

Which programming practice do we want to encourage:

1) "Hmmm. Slow vs fast. Well, heck, nobody will ever use my new code
   with a slow device. I'll just be lazy and not worry about EINTR."

2) "Hmmm, write() can return EINTR. I'll handle this properly in my new
   code."

By making the slow vs fast distinction in the man page we encourage 
practice #1. Is that really the right thing to do?

> I'm inclined to tweak the text with respect to mention of "slow" -- at
> least to include it as "historic" behavior..

Then go ahead and mention it as "historic", but mention as well that 
NetBSD does not guarantee this anymore. (Or change NFS if you insist
and then hope to goodness that NFS isn't the only exception forever
and ever.)

Incidentally, did anyone happen to comment on my "what's the best fix
for the NetBSD tree" question? 
-- 
Kevin P. Neal                                http://www.pobox.com/~kpn/

"It sounded pretty good, but it's hard to tell how it will work out
in practice." -- Dennis Ritchie, ~1977, "Summary of a DEC 32-bit machine"