Home > Archive > Unix Programming > April 2007 > portable non-blocking terminal input
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
portable non-blocking terminal input
|
|
| Frank Cusack 2007-04-11, 4:06 am |
| I want to set termios.c_cc MIN=1 and TIME=1, so that read() does a "full
read" of data returned from a serial port.
SUS 11.1.7
(http://www.opengroup.org/onlinepubs...p11.html#tag_11)
says that in this case (case A), the first byte is not timed and
therefore read() can block indefinitely. It also says that the
setting of O_NONBLOCK may or may not take precedence, and therefore
the setting of MIN and TIME may or may not be used. So I should make
sure O_NONBLOCK is not set in order to be sure MIN and TIME will be
honored. But then, how do I stop read() from blocking on the first
byte? (Even if I set O_NONBLOCK, it's not guaranteed to not block.)
I know how many bytes I have to read (there is a fixed header sent
which includes the count), so I could set MIN=0 TIME=1, and keep
issuing read() calls until I get all the data, but I was hoping there
is a more efficient way. The performance doesn't really matter, I'd
just prefer to have a cleaner solution.
-frank
| |
| Gianni Mariani 2007-04-11, 8:04 am |
| Frank Cusack wrote:
> I want to set termios.c_cc MIN=1 and TIME=1, so that read() does a "full
> read" of data returned from a serial port.
Using non blocking I/O and select() or poll() should work portably.
| |
| Frank Cusack 2007-04-11, 7:05 pm |
| On Wed, 11 Apr 2007 05:21:07 -0700 Gianni Mariani <gi3nospam@mariani.ws> wrote:
> Frank Cusack wrote:
>
>
> Using non blocking I/O and select() or poll() should work portably.
The section of SUS I referred to explicitly says O_NONBLOCK may be
ignored. There've been many discussions here that select() may give a
"false indication" of readability ... a read() would complete at the
time select() was done, but later (when you actually issue the read())
it might block. But at least for a serial port, maybe I don't have
to worry about this possibility.
-frank
| |
| Gianni Mariani 2007-04-11, 7:05 pm |
| Frank Cusack wrote:
> On Wed, 11 Apr 2007 05:21:07 -0700 Gianni Mariani <gi3nospam@mariani.ws> wrote:
>
>
>
> The section of SUS I referred to explicitly says O_NONBLOCK may be
> ignored. There've been many discussions here that select() may give a
> "false indication" of readability ... a read() would complete at the
> time select() was done, but later (when you actually issue the read())
> it might block.
That would make a whole bunch of applications very unreliable.
> ... But at least for a serial port, maybe I don't have
> to worry about this possibility.
It's been a long long time since I messed with serial port I/O but when
I did, I used select for detecting readability.
| |
| Frank Cusack 2007-04-11, 10:03 pm |
| On Wed, 11 Apr 2007 14:11:54 -0700 Gianni Mariani <gi3nospam@mariani.ws> wrote:
> Frank Cusack wrote:
>
> That would make a whole bunch of applications very unreliable.
1. You should review what you think you know about select() because
this absolutely does happen. Search google groups for endless
discussion on this in c.u.p.
2. There's no 2 ways about it; the careful reader of SUS cannot disagree
that select() is allowed to return "readable" yet read() can later block.
3. Most apps do NOT suffer this problem because, as you say, you should
use non-blocking I/O.
The problem I have is that for *terminal I/O*, O_NONBLOCK is
apparently allowed to be ignored. I need to support some very
non-mainstream platforms and cannot afford even to determine what the
implementation does, because I cannot afford to track possible changes
down the road. (Of course, not that any POSIX guarantee means I won't
have to deal with bugs of non-conformance. But that's a problem I can
work with.) Given that I don't trust these platforms, I don't want
to assume that I won't have the select()/read() problem for serial I/O.
-frank
| |
| Gianni Mariani 2007-04-12, 4:05 am |
| Frank Cusack wrote:
> On Wed, 11 Apr 2007 14:11:54 -0700 Gianni Mariani <gi3nospam@mariani.ws> wrote:
....
Given that I don't trust these platforms, I don't want
> to assume that I won't have the select()/read() problem for serial I/O.
Maybe your solution needs to be platform specific.
So the select non-block thing as default and where that does not work,
use some other platform specific mechanisms.
| |
| Jason Curl 2007-04-13, 8:03 am |
| Gianni Mariani wrote:
> Frank Cusack wrote:
>
> That would make a whole bunch of applications very unreliable.
>
My experience is Linux works well (I write only single threaded
application, so a read()/write() should only occur after a select()) and
I've seen often problems on Cygwin and Interix, especially with flow
control. I haven't tested Solaris Sparc or FreeBSD too well to say.
[color=darkred]
>
> It's been a long long time since I messed with serial port I/O but when
> I did, I used select for detecting readability.
|
|
|
|
|