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