On 4/4/14, Steve Williams <st...@williamsitconsulting.com> wrote: >> The POSIX writers erred by making VTIME an interbyte timer. > What real life problem are you trying to solve?
Theory of operation. > Why do you need to have < 250 bytes in the returned buffer? Same principle as a 16550 UART FIFO timeout. > Is it important to have a "steady 11 cps" in the other situation? Maybe. Depends on what's attached to the serial port. > Have you considered non-blocking IO? Using select or some other equivalent > to > determine if there is data available on the port prior to the read? Non-blocking select() returns for every byte. This hammers the CPU at high data rates. It's equivalent to blocking I/O with raw mode defaults (VMIN = 1 and VTIME = 0). Hammering the CPU is what I want to avoid. But at the same time, I want to eliminate any worst case, such as the 11 cps, 20 second delay. Maybe your application is mundane, and your data stream is randomly timed, such that an interbyte timer is "good enough" to avoid most delays. But ignoring the theory of operation and its pitfalls can make a system fail at the worst possible time; not what you want in a life critical situation. > Serial communications have been around since the dark ages & I was > writing code 20+ years ago to talk to RS-232 (a very un-standard > standard). There are many ways to solve the same problem... With DOS you have complete control. With POSIX systems the termios interface can be a hindrance.
