FW: util_ldap [Bug 29217] - Remove references to calloc() and free()

2004-06-11 Thread Mathihalli, Madhusudan
Another mail..

-Madhu 

>-Original Message-
>From: CHOU,TAIR-SHIAN (HP-Cupertino,ex1) 
>[mailto:[EMAIL PROTECTED] 
>Sent: Friday, June 11, 2004 7:05 PM
>To: Mathihalli, Madhusudan
>Subject: FW: util_ldap [Bug 29217] - Remove references to 
>calloc() and free()
>
>
>
>-Original Message-
>From: Tair-Shian Chou [mailto:[EMAIL PROTECTED]
>Sent: Friday, June 11, 2004 7:03 PM
>To: '[EMAIL PROTECTED]'
>Subject: RE: util_ldap [Bug 29217] - Remove references to 
>calloc() and free()
>
>
>Greg wrote:
>
>> then the compiler may optimize this as:
>> 
>> wrlock
>>test if exists again
>>allocate element
>>insert element
>>  >> race is here, prior to filling in element, another thread
>> may  >> read element, and use element that hasn't been filled in yet.
>>fill in element
>> unlock
>> 
>
>This can not happen because no reader can hold the rdlock 
>while a writer is holding the wrlock no matter how the 
>compiler optimize it.
>


FW: util_ldap [Bug 29217] - Remove references to calloc()and free()

2004-06-11 Thread Mathihalli, Madhusudan
I'm forwarding on behalf of my collegue (as his mails are not reaching
the list)

-Madhu 

>-Original Message-
>From: CHOU,TAIR-SHIAN (HP-Cupertino,ex1) 
>[mailto:[EMAIL PROTECTED] 
>Sent: Friday, June 11, 2004 7:04 PM
>To: Mathihalli, Madhusudan
>Subject: FW: util_ldap [Bug 29217] - Remove references to 
>calloc()and free()
>
>
>
>-Original Message-
>From: Tair-Shian Chou [mailto:[EMAIL PROTECTED]
>Sent: Friday, June 11, 2004 6:38 PM
>To: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'
>Subject: RE: util_ldap [Bug 29217] - Remove references to 
>calloc()and free()
>
>
>Brad Nicholes wrote:
>
>> 
>>   In fact, I don't think that these are shared locks at all
>> 
>> #define LDAP_CACHE_LOCK_CREATE(p) \
>> if (!st->util_ldap_cache_lock)
>> apr_thread_rwlock_create(&st->util_ldap_cache_lock, st->pool)
>> 
>> which means that in the shared memory cache, it is highly
>> likely that multiple processes could be altering the cache at 
>> the same time.  True? 
>> Since NetWare is multi-threaded only, we never see this problem.
>> 
>
>This is true. This creates a process-wide mutex, which can 
>only synchronize threads within the same process so multiple 
>processes can alternate the ldap cache at the same time.  This 
>was causing segmentation fault on HP-UX. We have fixed this by 
>creating a global mutex lock in util_ldap_cache_init();
>
>if (!st->util_ldap_cache_lock) {
>lock_file = apr_psprintf(pool,"%s.lock",st->cache_file);
>result = 
>apr_global_mutex_create(&st->util_ldap_cache_lock,lock_file,APR
_LOCK_PROC_PTHREAD,pool);
>if (result != APR_SUCCESS) {
>   return result;
>}
>
>We used mutex instead of rwlock because there is no apr* 
>function to create a global rwlock. 
>
>This change fixed the segmentation fault and other 
>synchronization problems.
>
>Chou
>