From owner-freebsd-hackers  Sun May 26 12:57:17 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id MAA12124
          for hackers-outgoing; Sun, 26 May 1996 12:57:17 -0700 (PDT)
Received: from cheops.anu.edu.au (avalon@[150.203.76.24])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA12119
          for <freebsd-hackers@freebsd.org>; Sun, 26 May 1996 12:57:10 -0700 (PDT)
Message-Id: <199605261957.MAA12119@freefall.freebsd.org>
Received: by cheops.anu.edu.au
	(1.37.109.16/16.2) id AA080590588; Mon, 27 May 1996 05:56:28 +1000
From: Darren Reed <avalon@coombs.anu.edu.au>
Subject: Re: Forgiving select() call.
To: imp@village.org (Warner Losh)
Date: Mon, 27 May 1996 05:56:28 +1000 (EST)
Cc: dutchman@spase.nl, freebsd-hackers@freebsd.org
In-Reply-To: <199605221701.LAA04803@rover.village.org> from "Warner Losh" at May 22, 96 11:01:03 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
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 ?

darren