portable non-blocking terminal input - Unix

This is a discussion on portable non-blocking terminal input - Unix ; 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/...11.html#tag_11 ) says that in this case (case A), the first byte is not timed ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: portable non-blocking terminal input

  1. portable non-blocking terminal input

    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/...11.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

  2. Re: portable non-blocking terminal input

    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.

  3. Re: portable non-blocking terminal input

    On Wed, 11 Apr 2007 05:21:07 -0700 Gianni Mariani wrote:
    > 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.


    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

  4. Re: portable non-blocking terminal input

    Frank Cusack wrote:
    > On Wed, 11 Apr 2007 05:21:07 -0700 Gianni Mariani wrote:
    >
    >>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.

    >
    >
    > 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.

  5. Re: portable non-blocking terminal input

    On Wed, 11 Apr 2007 14:11:54 -0700 Gianni Mariani wrote:
    > Frank Cusack wrote:
    >> On Wed, 11 Apr 2007 05:21:07 -0700 Gianni Mariani wrote:
    >>
    >>>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.

    >>
    >>
    >> 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.


    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

  6. Re: portable non-blocking terminal input

    Frank Cusack wrote:
    > On Wed, 11 Apr 2007 14:11:54 -0700 Gianni Mariani 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.

  7. Re: portable non-blocking terminal input

    Gianni Mariani wrote:
    > Frank Cusack wrote:
    >> On Wed, 11 Apr 2007 05:21:07 -0700 Gianni Mariani
    >> wrote:
    >>
    >>> 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.

    >>
    >>
    >> 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.


    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.

    >
    > 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.


+ Reply to Thread