[Date Prev][Date Next]
RE: (ITS#4662) ldap_create needs lock?
ldap_get_option(3) can be used to initialize the library
before spawning threads.
At 06:54 PM 9/11/2006, email@example.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
>Windows has it.
>Linux and Solaris have it (see
>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.
>From: Howard Chu [mailto:firstname.lastname@example.org]
>Sent: Monday, September 11, 2006 9:35 PM
>To: Bernie Volz (volz)
>Subject: Re: (ITS#4662) ldap_create needs lock?
>> Full_Name: Bernie Volz
>> Version: All
>> OS: Linux
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (220.127.116.11)
>> In ldap_create, if multiple threads are calling ldap_init (or one of
>> initialization functions), they may compete to initialize the global
>> this results in a segmentation fault.
>> Shouldn't the above code be conditionalized on LDAP_R_COMPILE and use
>> 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/