From owner-freebsd-current  Wed Oct 18 13:52:29 1995
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id NAA21489
          for current-outgoing; Wed, 18 Oct 1995 13:52:29 -0700
Received: from chrome.jdl.com (chrome.onramp.net [199.1.166.202])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA21468
          ; Wed, 18 Oct 1995 13:52:22 -0700
Received: from localhost.jdl.com (localhost.jdl.com [127.0.0.1]) by chrome.jdl.com (8.6.11/8.6.9) with SMTP id PAA11470; Wed, 18 Oct 1995 15:51:02 -0500
Message-Id: <199510182051.PAA11470@chrome.jdl.com>
X-Authentication-Warning: chrome.jdl.com: Host localhost.jdl.com didn't use HELO protocol
To: Terry Lambert <terry@lambert.org>
cc: bde@zeta.org.au (Bruce Evans), bakul@netcom.com,
        current@freefall.freebsd.org, hackers@freefall.freebsd.org
Subject: Re: getdtablesize() broken? 
In-reply-to: Your message of "Wed, 18 Oct 1995 12:39:49 PDT."
             <199510181939.MAA00690@phaeton.artisoft.com> 
Reply-To: jdl@chromatic.com
Clarity-Index: null
Threat-Level: none
Software-Engineering-Dead-Seriousness: There's no excuse for unreadable code.
Net-thought: If you meet the Buddha on the net, put him in your Kill file.
Date: Wed, 18 Oct 1995 15:51:02 -0500
From: Jon Loeliger <jdl@chrome.onramp.net>
Sender: owner-current@FreeBSD.org
Precedence: bulk

Apparently, Terry Lambert scribbled:
> > The select() interface has pointers to fd_set's, so it doesn't rule out
> > using arrays of fd_set's.  I think only the FD_ macros and the
> > documentation would need to be rewritten.
> 
> OK, I might buy this, though it seems a non-standard way of dealing with
> the issue.  I think the current bit macros would require modification to
> take address operands, or cast them to long arracys and linearly traverse
> them in any case.
> 
> Still, a passed "maxfd" in excess of the array max could have the kernel
> twiddling the the contents of non-select bit data areas.
>
> I think there is no way short of an interface change to cause the user
> to not have to supply a maxfd <= the actual array length limits, even
> if you make the kernel not care by breaking the FD_SETSIZE "agreement"
> between the kernel and the user programs.

Yea, and one further silly data point, that may or may not be even
vaguely interesting:  In AIX land, there were message queues too
and they needed the ability to be select()-able as well.  You couldn't
reliably have a second interface that only looked at msgques, as you
could only have one point of "hang" and it had to check for all the
possible select() conditions.

This led to the fd sets really having a message queue portion just after
the set of FD bits.  Naturally, in order to find where the first msg que
bits were, the length of the fd sets had to be known.

When msg queues were needed in the application, this had the further
interesting silly effect of not really being able to tell the select()
the honest number of "bits that are interesting" while doing the
select().  One had to lie and claim the maximum, even though the user
could be tracking the largest open fd and know full well that it was
much less than the maximum FD.  Icky and slow.

jdl