William A. Rowe, Jr.
Fri, 23 May 2008 13:05:54 -0700
Joe Orton wrote:
Ah right, you mean adding an API to expose that. Yeah, makes sense I suppose, but this is kind of piling on more and more layers of workarounds. An alternative maybe is to just create another unparented global pool here using the new 1.3 pool_core_create_ex API.
Trouble is, we *WANT* this pool cleanly torn down to invoke all of the appropriate destructors upon apr_terminate. That requires the global pool. It's not piling on, it's mainstreaming.
More review:1) the DSO-loading stuff is not thread-safe (dsos global not mutex-protected) yet apr_ldap_init would/could/should be; it's not documented to explicitly *not* be thread-safe, anyway.
The caller must obtain the mutex first, because the caller is responsible for initialization before releasing the mutex (it wouldn't do to acquire an uninitialized resource.) I'll document, as you suggest. I thought about a mutex within, but that would have required some flexible init callout and it seemed much more trouble than it's worth.
2) on the DSO-failed-to-load error paths it looks like *result_err should be set but won't be.
Will research, but if you have a patch that would save me some effort. Bill