Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 18 Oct 1995 15:51:02 -0500
From:      Jon Loeliger <jdl@chrome.onramp.net>
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? 
Message-ID:  <199510182051.PAA11470@chrome.jdl.com>
In-Reply-To: Your message of "Wed, 18 Oct 1995 12:39:49 PDT." <199510181939.MAA00690@phaeton.artisoft.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510182051.PAA11470>