Re: SER: select() -> poll() (ITS#2957)

[Kurt@OpenLDAP.org]

Well, personally, I haven't pursued a poll()-based solution
because I haven't needed it.  select() works just fine for
me.  It's unfortunate that glibc is designed not to allow
applications to grow fd_set structure as needed (as commonly
allowed in other select() implementations) (or be shipped
with a fd_set structure able to handle the maximum number of
descriptors a process can have open).

I note that one reason why select() has been historically
favored over poll() in OpenLDAP is OpenLDAP's use of pthreads
(and other threading APIs).  It's unclear whether poll()
interacts with pthreads in a consistent and reasonable manner
across most platforms (like select() does).

And then, of course, some would argue that other alternatives
are better.

That said, I think it would be nice to have an optional
poll-based listener implementation.  Contributions welcomed.

Kurt

At 10:44 AM 2/6/2004, bevan@fulcrummicro.com wrote:
>Full_Name: Bevan Bennett
>Version: 2.1.25
>OS: Fedora Core 1
>URL: ftp://ftp.openldap.org/incoming/
>Submission from: (NULL) (65.119.15.91)
>
>
>--software enhancement request--
>As noted in Incoming/2813 and elsewhere, openldap 2.1.22/25 with a standard
>glibc will hang under moderate-heavy load when select() becomes unable to access
>more file descriptors.
>
>The usual offered suggestions are to either recompile glibc on the effected
>systems or to switch openldap from select() to poll().  The latter would seem to
>be a better solution towards making openldap generally enterprise-capable, and
>involves messing with far fewer dependencies than modifying glibc does.
>
>Would someone more familiar with the nuances and dangers of select/poll like to
>offer this alteration, or a brief explanation of why it doesn't seem to be being
>pursued?
>(I checked 2.1.26 and 2.2.5, and they all have the same select() calls as
>2.1.22.)