RE: (ITS#4662) ldap_create needs lock?

[Kurt@OpenLDAP.org]

ldap_get_option(3) can be used to initialize the library
before spawning threads.

At 06:54 PM 9/11/2006, volz@cisco.com 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.
>
>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 
>
>-----Original Message-----
>From: Howard Chu [mailto:hyc@symas.com] 
>Sent: Monday, September 11, 2006 9:35 PM
>To: Bernie Volz (volz)
>Cc: openldap-its@OpenLDAP.org
>Subject: Re: (ITS#4662) ldap_create needs lock?
>
>volz@cisco.com wrote:
>> Full_Name: Bernie Volz
>> Version: All
>> OS: Linux
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (64.102.254.33)
>> 
>> 
>> 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/