Re: Serial communication and EOF?

Geoff Clare wrote:
Jef Driesen wrote:
Geoff Clare wrote:
Jef Driesen wrote:
When non-blocking I/O is used (by opening the port with O_NONBLOCK or setting both c_cc[VMIN] and c_cc[VTIME] to zero) and no data is available for reading, read() can return zero or -1 with errno==EAGAIN (according to the man pages both are possible). But if zero can also indicate EOF, it becomes impossible to detect the difference.
If you want to be able to detect the difference, then set c_cc[VMIN]
non-zero.
Do you mean setting c_cc[VMIN] to non-zero in addition to using
O_NONBLOCK?

Yes.

The VMIN > 0 prevents the read() from returning zero, but
will also cause the read() to block when no data is available. And
that's not what I want. But the posix man pages say this about using
O_NONBLOCK:

"The ISO POSIX-1 standard does not specify whether the setting of
O_NONBLOCK takes precedence over MIN or TIME settings. Therefore, if
O_NONBLOCK is set, read() may return immediately, regardless of the
setting of MIN or TIME. Also, if no data is available, read() may either
return 0, or return -1 with errno set to [EAGAIN]."

I interpret that as read() can return zero again with O_NONBLOCK
enabled.

I can see how that part of POSIX could be read as applying to the
MIN = 0 case, but I'm sure that is not the intention. What it is
trying to say is that as a consequence of there being no precedence,
in cases where read() with O_NONBLOCK clear would have returned 0
because no data are available, with O_NONBLOCK set it can either
return 0 or return -1 with errno EAGAIN.

If you look at the descriptions of the MIN > 0 cases, there is no
reference to read() ever returning zero. So in those cases, there
is no precedence issue and the normal requirement for -1 with EAGAIN
applies.

Thanks for the clarification.

And what if I use select() before the read() call to check if the file descriptor is ready for reading? Does the next read() call always return a value greater then zero? Or is zero still possible?
Zero is still possible.
Is that because read() does never block on EOF and thus select()
always indicate the file descriptor is ready for reading without blocking?

Partly. As has been discussed in this group before (usually in
relation to sockets), select() only tells you that if a read() call
(with O_NONBLOCK set) had been made at the time that select() was
called then that read() would not have blocked. It does not necessarily
mean that that read() would have returned a value greater than zero,

I assumed that when select() returns "ready for reading", this automatically means there is data available for reading. And that was causing much of my confusing. The posix man pages explain this more explicit than the man pages of my linux system: (why didn't I read that page earlier...)

"A descriptor shall be considered ready for reading when a call to an input function with O_NONBLOCK clear would not block, whether or not the function would transfer data successfully. (The function might return data, an end-of-file indication, or an error other than one indicating that it is blocked, and in each of these cases the descriptor shall be considered ready for reading.)"

So select() does not say anything about the result of the read() call, except that it does not return EAGAIN. But *if* there is data available, there are least VMIN bytes available (which can be zero), otherwise read() would have blocked and select() shouldn't have returned "ready for reading". Right?

and it does not guarantee that a read() call made after the select()
returns will not block. Therefore to ensure read() cannot block you
would still have to either set O_NONBLOCK or set MIN = 0.

This is something I do not understand. If the file descriptor was ready for reading at the time of the select(), how can that condition change? How could bytes that were previously available (or an error condition) disappear?

For writing I can understand why O_NONBLOCK is necessary, because select() does not tell how much data can be written without blocking. And O_NONBLOCK can be used to write as much as possible in that case.
.

Relevant Pages

  • Re: Serial communication and EOF?
    ... Or is zero still possible? ... always indicate the file descriptor is ready for reading without blocking? ... are other things that can cause the data to disappear. ...
    (comp.unix.programmer)
  • Re: Serial communication and EOF?
    ... if I use selectbefore the readcall to check if the file descriptor is ready for reading? ... Does the next readcall always return a value greater then zero? ... But *if* there is data available, there are least VMIN bytes available, otherwise readwould have blocked and selectshouldn't have returned "ready for reading". ...
    (comp.unix.programmer)
  • Re: Not knowing how to read the statistics
    ... How should I read the statistics below? ... reading it, depending on who is doing the reading and both ... or "Plus or minus point two five (one oh; or one zero) millimeters". ... between American usage and British usage on this. ...
    (sci.stat.math)
  • RE: Please HELP!!
    ... Well if I am reading ok, then your most useful, and adecuate ... I enter a sales figure for each department and each week. ... chart and a line chart set up with the range being the all department ... as zero and plotting all future weeks at zero, ...
    (microsoft.public.excel.misc)
  • Re: C++ Prob with Programming Exercise in a Book
    ... Take user input, display a cummulative total, and use ... >>zero to terminate the program. ... I thought that using a zero wouldnt be ... You're reading from the standard ...
    (alt.comp.lang.learn.c-cpp)