[Date Prev][Date Next]
RE: (ITS#3967) Use of select in os-ip.c
That's welcome news. Thanks very much. Feel free to close out the
incident and we'll pick up a 2.3 version a bit later when our release
cycle permits. I have to appologize...I glanced over the 2.3.x versions
on the download page. Would have looked at them had I seen them.
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Tuesday, August 23, 2005 9:16 PM
Subject: Re: (ITS#3967) Use of select in os-ip.c
2.3 libldap supports poll(3)...
At 04:38 PM 8/23/2005, firstname.lastname@example.org wrote:
>Full_Name: Jeff Lewis
>Submission from: (NULL) (126.96.36.199)
>This is something to add to the wish-list for a future enhancement
>rather than a bug report.
>The OpenLDAP client likes to use select() to wait on fds to become
>ready for reading or writing. In our environment, it would be better
>if OpenLDAP could make use of poll() instead and build its pollfds up
>The reason this is important to us is we run in a server environment
>where there can be over 5000 open files when we're under extreme load.
>Additionally, we do occasional LDAP queries that result in us typically
>using 1 fd inside the OpenLDAP client and that fd can be quite large.
>To allocate fd_set structures (4, I think) for one very large fd is
less than optimal from our point of view.
>For us, poll would be a much better choice.
>It would be nice if OpenLDAP had a knob of some sort that would allow
>us to use poll instead of select. If the configure script could figure
>that out, so much the better. Even if OpenLDAP uses select by default,
>but gives us an OPENLDAP_POLL macro or something similar that we could
>use in a -D option on the compile commands would be hugely appreciated.
>As far as which O/S's we use, they are:
> AIX (32 and 64 bit Power)
> HP-UX (ia64, 32 and 64 bit PA)
> MP-RAS (our own proprietary SRV4 variant) Linux (Red Had for ia64,
> x8664, i386; SuSE for x8664 and i386) Solaris (32 and 64 bit Sparc)
>I did check the latest stable source release and it appears to still
> I'd be very happy to learn that I'm wrong about that. :-)