questions about select and non-blocking I/O

[Chris Torek]

Well, *because* it doesn't check the return value of select it
needs to be careful in the presence of signals.  However I always
thought the telnet code was a bit silly myself.  Besides, the only
signals telnetd should ever get should just kill it off anyway....

> This `sleep' seems really silly - select is perfectly capable of
> waiting for one of the events to come ready. Since none of the
> conditions will change before we get here again I would think that a
> select call with a "wait_until_something_is_ready" (i.e. &NULL) would
> have much less overhead (one would have to check the return code for
> interrrupted system call). 

Not &NULL, rather (struct timeval *)NULL, but yes....

> doesn't anyone trust `select' to tell the truth?

I guess not.  Also remember that select does what is arguably the
wrong thing in the presence of mismatched process groups (claims
the read won't block when it will actually generate a SIGTTIN).
Again this should never happen to telnetd anyway.

Chris
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris at umcp-cs		ARPA:	chris at maryland