This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: ser*.[hc] cleanup
- To: ac131313 at cygnus dot com (Andrew Cagney)
- Subject: Re: ser*.[hc] cleanup
- From: Todd Whitesel <toddpw at windriver dot com>
- Date: Tue, 30 Nov 1999 23:09:58 -0800 (PST)
- Cc: gdb-patches at sourceware dot cygnus dot com (GDB Patches)
> 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.
--
Todd Whitesel
toddpw @ windriver.com