From owner-freebsd-hackers Sun May 26 17:04:05 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA17452 for hackers-outgoing; Sun, 26 May 1996 17:04:05 -0700 (PDT) Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA17348 for ; Sun, 26 May 1996 17:03:59 -0700 (PDT) Received: from exalt.x.org by expo.x.org id AA27572; Sun, 26 May 96 20:03:23 -0400 Received: from localhost by exalt.x.org id UAA16209; Sun, 26 May 1996 20:03:20 -0400 Message-Id: <199605270003.UAA16209@exalt.x.org> To: Darren Reed Cc: hackers@freefall.FreeBSD.org Subject: Re: Forgiving select() call. In-Reply-To: Your message of Mon, 27 May 1996 05:56:28 EST. <199605261957.MAA12119@freefall.freebsd.org> Organization: X Consortium Date: Sun, 26 May 1996 20:03:20 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > In some mail from Warner Losh, sie said: > > > > : I want to modify select(2) to return the `timeout left' as described in the > > : BUGS section of the manual page. Any reason why I should not? > > > > That is *********NOT******* how select works. Too many programs do > > not do the right thing when this is done. The failure mode is that > > things seem to work but you have no CPU left for other thigns. Ths is > > a *VERY*BAD* idea. Linux tried it and now they have bsd compatible > > select behavior unless you go our of your way to get the behavior you > > propose. Why? Too many programs were eating the CPU for lunch > > because they were poorly programmed. And there were too many to > > easily fix all of them. Linux is the *ONLY* system that changes the > > timeval in the select call. > > > > It is a bad idea. If it had been a good idea, then Lite or Lite2 > > would have had it changed. The bug in the man page is really a bug > > with the man page by now, imho. > > > > If you want to have a system call that returns this information, don't > > call it select. > > Any thoughts on writing a poll() which allows a variable number of bits > passed in the fd_set (or new) structure to get around FD_SETSIZE limits Poll is (finally) specified in Spec1170 and it doesn't use bits in an fd_set. If you want a system call that does this, don't call it poll. -- Kaleb KEITHLEY