> David Schwartz wrote:
> > A patch to use 'poll' instead of 'select' where it's
> > available would be a
> > very good idea. Using 'select' to check readiness of a single descriptor
> > that you just opened is about the worst-case scenario for
> > 'select' (because
> > it has to scan through all the unset bits on each set). Using
> > 'poll' is far
> > more efficient for a single descriptor since no scanning is needed.
> The performance of finding the first set bit from a 128byte block of
> data really isn't that bad inside the kernel. Faster than a strcpy() of
> a 128byte string I'd say, as there is no memory writing going on. Its
> also probably still in CPU the cache as your just did FD_ZERO()/FD_SET()
> on it.
[snip]
You are right that my claim that it's "far more efficient" is probably
an
exaggeration. Nevertheless, fixing the problem that the library has no way
of knowing how big the fd sets should be still makes the change worthwhile.
I believe there is no reliable, portable, safe way to use 'select' on a
file descriptor you open in a library. No matter how big or small the
descriptor is, there's is no guarantee it will fit in an fd set. On every
UNIX I know of, comparing the descriptor to '8 * sizeof(fd_set)' will work
(as will hacks to make your own larger fd set structures), there's no
guarantee that fd sets are bitfields. 'FD_SETSIZE' should work if it's
defined. Sadly, 'getdtablesize' is notorious for giving you the wrong
information (since it has no way of knowing which of the various limits you
actually want and they can differ if, for example, the ulimit on the number
of open files at run time is larger than the fd set size was at compile
time).
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
