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>