Re: ser*.[hc] cleanup

[Andrew Cagney <ac131313 at cygnus dot com>]

Todd Whitesel wrote:
> 
> > In going through this I noticed that ser-unix.c implements non-blocking
> > reads using either select() or TERMIO/TERMIOS calls (?).
> 
> Yes! The VMIN/VTIME parameters let you do all kinds of cool stuff on the
> serial port, like block until a burst of characters comes in, returning from
> the read() as soon as the line goes quiet for some fraction of a second. Used
> properly, it handily beats a select() implementation -- unless you need the
> extra flexibility of select() of course.
> 
> > I'm wondering if the TERMIO/TERMIOS code that causes timeouts is now
> > redundant.  It would appear that we're assuming select() anyway (c.f.
> > event-loop.c).  That would allow me to be even more ruthless :-)
> 
> Around 1996 or so, I did a survey of all the obscure machines at Green Hills
> in an attempt to resolve this very question. They were all okay except:
> 
> There is at least one old sysV variant (SCO, 3.2something I think) that
> has select() for sockets ONLY, and doesn't allow select() on serial ports.
> Worse, it didn't even have FIONREAD. I ended up simulating that with a V7
> ioctl I spotted in the system headers, but it wasn't pretty -- I had to
> preserve the gross "call alarm, then read, and maybe longjmp out of a signal
> handler to abort the read" method just for this one host.
> 
> I'd say we should look at select() like ANSI C -- we've waited long enough,
> let's just do it and wait for someone to cry uncle.

We've actually kind of done it.  The event loop already requires
select() or poll().

	Andrew