On 27.09.2013 12:29, Florian Weimer wrote: > * Branko Čibej: > >> If the application that uses your library also uses APR directly, it's >> already responsible for initializing it in a single-threaded context. If >> it doesn't, it's reasonable to require the app to call your library's >> init function, which you can easily protect with a spinlock (that you >> can implement using APR's atomic functions). > It's still problematic if you've got multiple libraries which use APR > internally (without exposing it) and perform some form of lazy > initialization. > > Pushing initialization sequencing to the application is really bad, > and it's totally unnecessary on modern systems which always provide > mutexes, even to single-threaded processes (where they are no-ops).
Oh, I agree. The problem with APR is, of course, that its thread mutex APIs require a pool ... so there's a chicken-and-egg situation. And AFAIK there are still versions of Windows in use that do not have any kind of synchronization primitive that could be statically initialized. I have no idea about Netware etc., or whether multi-threaded initialization is even a problem there. The only reasonably cross-platform way to get single-threaded apr_initialize and apr_terminate that I can think of is to write our own poor-man's spinlock, based on the atomic CAS functions that happily do not expect a pool. -- Brane
