RE: (ITS#4662) ldap_create needs lock?

[volz@cisco.com]

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/