> What the hell are you talking about? CTS is a flow control signal which
> means that the serial port should cease transmitting. It should
> certainly not block the process. Read the POSIX.1 spec; it makes no
> such requirements. If the process is busy reading from the serial port,
> and you block it, then you can end up deadlocking the whole
> communications protocol. No Unix system in the world has ever done
> things the way you've described it, because it's broken. CTS has a very
> well defined meaning, and it means to stop transmitting. It doesn't
> mean to stop anything else.
I was under the understanding that when CTS goes low, we should in fact be
blocking entirely, until CTS does come back high. (Hence, a remote device
can now process its RX queue, and at such time as it can receive more
data, it brings up whatever output signal thats wired into OUR CTS.)
I can certainly see your point, here.
NOTE: POSIX doesn't define this, no. but they don't define against it,
either, so interpretation is hit-or-miss, at best.
Yes, you have an arguable point, that we really shouldn't be blocking the
entire process. (It is useful to be able to read().) But obviously, if we
write(), we should either A) block, or B) let us fill up the entire kernel
write buffer we've set up, before we block. (Again, not defined.)
Chad
-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to [EMAIL PROTECTED]
