apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@apache.org>
Subject Re: thread safety of apr_initialize
Date Fri, 27 Sep 2013 13:12:53 GMT
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

Mime
View raw message