[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: read() and POSIX compliance
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...