[Date Prev][Date Next]
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?
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
>Submission from: (NULL) (220.127.116.11)
>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.