[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: CPU load at 100% on Windows 2000 (ITS#697)
For me it works now.
Thanks,
George Aprotosoaie
----- Original Message -----
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
To: <gaprotosoaie@adexa.com>
Cc: <openldap-its@OpenLDAP.org>
Sent: Tuesday, September 12, 2000 8:45 PM
Subject: Re: CPU load at 100% on Windows 2000 (ITS#697)
> Changes applied to HEAD and OPENLDAP_REL_ENG_2, please test.
> Thanks, Kurt
>
> At 03:56 PM 9/12/00 +0000, gaprotosoaie@adexa.com wrote:
> >Sorry, I was not able to find a way to submit changes fast.
> >
> >I have seen the bug and I fixed it long ago (the procedure to send
> >fixes back is too complicated for me). It happens an all Windows
> >platforms (NT and 2000) and it is been here long enough.
> >
> >It is easy to fix: comment out the "ReleaseMutex( *mutex );" line from
> >"libldap_r/thr_nt.c", function "ldap_pvt_thread_cond_wait".
> >"ReleaseMutex" is doing what the first step from "SignalObjectAndWait"
> >should do: release the mutex. With the "ReleaseMutex" line in, when
> >the "SignalObjectAndWait" attempts to release the mutex, it fails and
> >returns an error, without blocking - since the 100% CPU usage.
> >With the line removed, "SignalObjectAndWait" does the proper job and
> >the thread is blocked later on with: 0% CPU.
> >
> >int ldap_pvt_thread_cond_wait ( ldap_pvt_thread_cond_t *cond,
> >ldap_pvt_thread_mutex_t *mutex )
> >{
> > //ReleaseMutex( *mutex );
> > SignalObjectAndWait( *mutex, *cond, INFINITE, FALSE );
> > WaitForSingleObject( *mutex, INFINITE );
> > return( 0 );
> >}
> >
> >
> >Regards,
> >George Aprotosoaie
> >
> >
> >
> >
> >
> >Date: Wed, 06 Sep 2000 15:52:26 -0700
> >To: Marcello.Formica@compaq.com
> >From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
> >Subject: RE: CPU load at 100% on Windows 2000 (ITS#697)
> >Cc: openldap-its@OpenLDAP.org
> >
> >At 09:37 PM 9/6/00 +0000, Marcello.Formica@compaq.com wrote:
> >>Done; exactly the same situation (CPU raises to 100% as soon as I try to
> >>browse the directory via ADSVW).
> >>Anyway, I found out that if I compile with single-threaded libraries
> >(Active
> >>Project Configuration = "build - Win32 Single Release", in Visual
Studio),
> >>this behaviour doesn't happen.
> >
> >Thanks for retest. Looks like we need a MSVC-aware developer
> >to look into this...
>