Re: ldap_pvt_thread_cond_broadcast not functioning (ITS#1875)

[Kurt@OpenLDAP.org]

Kurt,

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 
version.

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?

Regards,
-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, btstout@earthlink.net 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) (204.62.9.73)
>
>
>The ldap_pvt_thread_cond_broadcast() implementation seems broken for win32
>systems.  Specifically, only a single thread is awakened when there are
>multiple
>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
>replicants,
>only one recieves an update since not all replicant threads in slurpd become
>active
>when broadcast is executed by the fm thread.  If have been able to work around
>the
>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.