Linux serial port programming problems

[j***@hotmail.com]

what is the difference between blocking versus non blocking serial IO.
jim

[Robert Harris]

Post by j***@hotmail.com
what is the difference between blocking versus non blocking serial IO.
jim

Blocking: read() waits until there is input. The amount of input
required to satisfy the read depends on different factors, e.g. the
number of bytes requested, whether a LF character has been received in
canonical mode or whether VMIN and VTIME values are satisfied in
non-canonical mode.

Non-blocking: read() returns immediately even if there is no input

Robert

[Floyd L. Davidson]

Post by j***@hotmail.com
what is the difference between blocking versus non blocking serial IO.
jim

The difference is whether a system call will wait until it can
successfully accomplish a task, or return immediately with an
error indicating that the task cannot be accomplished at that
moment.

For example, the most common instance with serial port
programming would be when you attempt to fetch incoming data
from the serial port. Your application either calls the read(2)
system call or calls some library function which does call
read(2). If read(2) can return data to you, there is no
difference between "blocking IO" and "non-blocking IO".
However, if there is no data to return, with "blocking IO" the
call to read(2) will simply not return until 1) there is data,
2) an EOF condition exists, or 3) there is an error condition.

With "non-blocking IO" the lack of data is itself an "error",
and your application can detect that (and simply ignore it, for
example).

There are at least two other permutations which are of interest.
One is that if a serial port is configured to use "modem control
lines" and blocking IO, a call to open(2) on the device special
file will not return until the DCD line indicates a connection
is available. That works great for hardwired devices directly
attached to the serial port, particularly if they need to wakeup
and initialize themselves when your application connects. But
if the device is a modem... outgoing calls require working with
the modem when the DCD line indicates no connection. Hence in
that case the serial port is opened in non-blocking mode (and
then is commonly switched immediately to blocking mode to
perform read/write operations that communicate with the modem).

The other variation is when a serial port is in raw mode (no
post processing of the input buffer), there are differences in
the way the timer function works, when struct termios members
VTIME and VMIN are set to 0 or not. The timer can affect how
long a call to read(2) will block.

There is one last point to make, since you have crossposted this
to a Linux group. O_NDELAY is not defined by POSIX, and
O_NONBLOCK is. O_NDELAY may have slightly different
characteristics on different platforms, but O_NONBLOCK should
produce exactly the same results on any platform. On Linux they
happen to be exactly identical. (Obviously, for portable code,
O_NONBLOCK is preferred.)