[Date Prev][Date Next]
RE: ldap_pvt_thread_cond_broadcast not functioning (ITS#1875)
Some patches for slurpd on NT are in the CVS HEAD and in 2.1. They haven't
been ported back into the 2.0 source. I've built slurpd on NT using MinGW,
haven't tried using MSVC, so I don't know if it will work there.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support
> -----Original Message-----
> From: owner-openldap-bugs@OpenLDAP.org
> [mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of Kurt@OpenLDAP.org
> Sent: Monday, June 10, 2002 12:54 PM
> To: openldap-its@OpenLDAP.org
> Subject: Re: ldap_pvt_thread_cond_broadcast not functioning (ITS#1875)
> When I stated 2.0.18-Current as the version, I was referring to
> the current stable release (2.0.23). This broadcast problem has
> indeed been corrected
> in 2.0.24. I was not aware of this. Thanks
> for pointing it out. I have tested my
> replication scenario with the .24 version
> of thr_nt.c and it works fine. Sorry for the
> bug report. I should have been more thorough
> and looked through the latest development
> By the way, it appears to me that .24 slurpd does not include the
> very minor additions needed for a working slurpd under win32
> (previous versions
> didn't as well) I (as well as many other folks I'm sure) have a
> need for slurpd on win32. I would like for these additions to be
> considered for incorporation into the main codebase.
> Should I submit a patch form or is there a
> specific individual I should contact?
> -Todd Stout
> On Mon, 10 Jun 2002 10:42:48 -0700 "Kurt D. Zeilenga"
> <Kurt@OpenLDAP.org> wrote:
> At 09:54 AM 2002-06-10, firstname.lastname@example.org wrote:
> >Full_Name: Todd Stout
> >Version: 2.18 - Current
> Current as in 2.0.24?
> >OS: Win NT/2000
> >URL: ftp://ftp.openldap.org/incoming/
> >Submission from: (NULL) (188.8.131.52)
> >The ldap_pvt_thread_cond_broadcast() implementation seems broken
> for win32
> >systems. Specifically, only a single thread is awakened when there are
> >threads waiting on the condition variable. This does not seem
> to present a
> >problem for slapd since it does not rely on broadcast (it only
> uses signal).
> >This presents a problem for slurpd however, since there is a
> thread for each
> >replication entry in slapd.conf. Under win32, when there are multiple
> >only one recieves an update since not all replicant threads in
> slurpd become
> >when broadcast is executed by the fm thread. If have been able
> to work around
> >problem by changing slurpd to include a condition variable per
> replicant thread
> >and faking the broadcast by signaling each condition variable.
> >However, it would be cleaner to correct the cond_broadcast
> implementation to
> >avoid win32 specific code in slurpd.