Re: read() and POSIX compliance

[Juergen Lock <nox@jelal.north.de>]

Nicholas S Castellano writes:

> POSIX introduces the O_NONBLOCK flag which causes the read() to return
> -1 with errno set to EAGAIN, when the file has no data available but
> is not an end-of-file condition.

 (other names are O_NDELAY and EWOULDBLOCK...)
> 
> I'm thinking along these lines:
>   -call Fcntl(fd, &nbytes, FIONREAD)
>   -call Fread(...)
>   -if Fread() returns 0:  then if nbytes is 0 return -1 with errno =
> 	EAGAIN, otherwise return 0 signifying end-of file.
> 
> This seems valid for the TOS filesystem (since it always gives 1 for
> FIONREAD it will never give EAGAIN) and for the pipefs (which will
> give -1 for FIONREAD at end-of-file [that is, when the other side of
> the pipe is closed] and 0 if there is just no data ready).
> 
> This reasoning breaks down, however, in the case of a device such as
> the shmfs.  This device will give 0 bytes for an FIONREAD when at
> end-of-file, so using the above scheme would mean a non-blocking
> read() on shmfs would never return 0.

 there's more to it...  on ttys 0 can mean no data available, it can
mean `eofc read' (i.e. got ^D) and, should we get a better serial driver
some day that doesn't always think its in local mode :) then it can also
mean `hangup'.  the first case should become EAGAIN, the others not...

 oh and of course between FIONREAD and the actual Fread call you also
have a wonderful race. :-)  i.e. whats when data becomes available just
before it calls Fread...
> 
> I'm a bit stumped.  I think it will be necessary to define the exact
> action of FIONREAD at end-of-file for device drivers in some
> consistent manner in order to make it possible to distinguish EOF from
> a lack of available data.

 i think the only way to get this work is change the kernel and device
drivers `read' functions.  and then maybe turn EAGAIN back into 0 for
TOS domain processes.

 only problem, it seems Eric never has time...

 cheers
	Juergen