Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site umcp-cs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.unix-wizards
Subject: Re: questions about select and non-blocking I/O
Message-ID: <871@umcp-cs.UUCP>
Date: Tue, 16-Jul-85 00:33:50 EDT
Article-I.D.: umcp-cs.871
Posted: Tue Jul 16 00:33:50 1985
Date-Received: Thu, 18-Jul-85 03:46:44 EDT
References: <585@alberta.UUCP>
Distribution: net
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 26

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@umcp-cs		ARPA:	chris@maryland