Re: (ITS#4662) ldap_create needs lock?

[hyc@symas.com]

Bernie Volz (volz) wrote:
> What about registering an initialization entry point when the library is
> loaded? Though that only solves the problem when the .so/.dll is used;
> not when someone links directly with the object module.
> 
> Though I do find it difficult to believe static initialization isn't
> possible?
> 
> Windows has it.

Hm, last I checked, Windows does not have it. Most people seem to solve 
this by using a constructor. (I.e., a small init function that runs at 
DLL load time.)

Of course, you could avoid the problem by simply calling an appropriate 
libldap function in the main process, before spawning any child threads.
> 
> Linux and Solaris have it (see
> http://www.die.net/doc/linux/man/man3/pthread_mutex_init.3.html).
> 
> Sure, you'd need a #define or something similar that works on all
> platforms, but that shouldn't be that difficult? I've done so for
> Windows, Solaris, and Linux.
> 
> - Bernie 

>> In ldap_create, if multiple threads are calling ldap_init (or one of
> the other
>> initialization functions), they may compete to initialize the global
> options and
>> this results in a segmentation fault.
> 
>> Shouldn't the above code be conditionalized on LDAP_R_COMPILE and use
> a static
>> global mutex to assure that only one thread is testing and potentially
>> initializing the global options.
> 
> Unfortunately static mutex initializers are non-portable. I guess for 
> gcc we could arrange to have a constructor do the initialization, but 
> it's not clear what we can do for the more general case.
> 


-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc
   OpenLDAP Core Team            http://www.openldap.org/project/