apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: apr_palloc is not thread safe
Date Fri, 31 May 2013 11:06:33 GMT
On 31 May 2013, at 6:15 AM, TROY.LIU 劉春偉 <TROY.LIU@DELTAWW.COM.CN> wrote:

> Thanks for reply, I got it.  Now the problem is my APIs does not expose apr_pool_t to
user like apr,  so my APIs are not thread safe.

The typical way you use a pool is that pools are arranged logically in a hierarchy. So a process
would have a pool, then one subpool of the process pool for each thread, and then one subpool
per unit of work (for example a connection handled by the thread).

It is not the job of pools to dictate to you how you should arrange your pools, that is your
job. Trying to add mutexes to an API that doesn't need to be threadsafe is a waste of resources,
so it is left up to you to decide how your pool usage remains threadsafe.

In the above example, there is no need for any locks, because the per thread pool would only
be used by that thread. You might have a pool representing a connection, and you might allow
that connection to be handled by any thread, but as long as just one thread handles that connection
at any given time you get away with not needing locks still.

It is only when the pool is attached to something that does span threads, such as a database
connection pool, that you start needing locks, in which case use the mutex APIs to use the
locks you need.

Again, APR gives you choice: do you use an in-process thread lock, or a machine wide process
lock, which you choose is up to your application's needs.


View raw message