But I don't wanna do non-blocking I/O...

[John Chambers]

In article <1990Jun12.203245.5804 at virtech.uucp>, cpcahil at virtech.uucp (Conor P. Cahill) writes:

Hey, thanks for the help!  Needless to say, I *do* have further comments...
(;-)

> >calling a shell.  The open() does include F_NDELAY, but
>                                            ^^^^^^^^  I assume you mean O_NDELAY

Yah; that was a typo.  Too bad there isn't a version of lint for news
articles.  But being a human, you guessed what I meant.

> >this is supposed to apply only to the open; it shouldn't
> >set non-blocking I/O permanently for the file (I hope ;-).
>
> You should RTFM (specifically the read(2) man page). Therein you should
> find a paragraph similar to the following:
> 	When attempting to read a file associated with a tty that has no data
> 	currently available:
> 		If O_NDELAY is set, the read will return 0.
> 		If O_NDELAY is clear, the read will block until data becomes
> 		available.

Hey, whadday you know, I actually found it in one copy of TFM.  I first
looked it up in various other Unix manuals I happen to have lying about
(souvenirs, you know), and didn't find it in them, but I just got a copy
of the System V/386 Release 32 (really!) Programmer's Reverence Manual
(that was a typo, too, honest it was, but it's too good to correct ;-), 
and there is is in black and white....  In the morning, I'll check with 
the Ultrix manuals at work and see what they say.  If they're true to
form, they won't mention the subject; anyway, the code works find on
Ultrix, since I figured out that PMAX/Ultrix doesn't do non-blocking I/O.

> If you don't want this behavior, you should use the fcntl(2) to turn
> off the O_NDELAY once the open has returned.

Which reminds me that the ATT people seem to be unlearning what little
they used to know about writing manual pages.  The fcntl(2) page doesn't
even come close to explaining the situation.  It does refer the reader
to fcntl(5), but even then the explanation isn't exactly obvious to the
meanest intelligence.  For starters, it gives a code (F_SETFL) for setting
flags, but it doesn't have a code for resetting the flags once they've
been set, which is what I wanted to do.  This was a bit of a puzzle, 
until I finally re-oriented my brain and guessed what they were hinting
at.  (OK, I've been programming too long; what can I say? But I won't
give away the ending to those who haven't read the book... ;-)  

Anyhow, that did solve the problem.  It also meant that I expanded my
#defines to include SYS5_2 and SYS5_3.  In any case, it looks like one 
more thing to remember when trying to write portable code.  It ain't 
getting easier.  I can hardly wait for the Sys/5.4 release.  By then
maybe I'll be porting stuff to Mach, and going totally insane.

(Now if I could only decrypt what the manuals say about process groups. :-)

-- 
Uucp: ...!{harvard.edu,ima.com,eddie.mit.edu}!minya!jc (John Chambers)
Home: 1-617-484-6393
Work: 1-508-952-3274
Cute-Saying: It's never to late to have a happy childhood.