You do not need to expose pools to users through your API to make their
usage thread safe. Identify the spots which can trigger pool access and
wrap some thread safety mechanism around them, e.g. mutexes. APR does
supply you with good means to get your code thread safe - just use it ;-)

Look up
  http://apr.apache.org/docs/apr/1.4/group__apr__proc__mutex.html
or
  http://apr.apache.org/docs/apr/1.4/group___a_p_r___global_mutex.html
depending on what kind of thread safety you are interested in - within one
process or across process borders.

Cheers,
  Thomas

On Fri, May 31, 2013 at 6:15 AM, TROY.LIU 劉春偉 <troy....@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.
>
> Best Regards
> Chunwei Liu
>
> -----Original Message-----
> From: Philip Martin [mailto:codematt...@ntlworld.com] On Behalf Of Philip
> Martin
> Sent: Thursday, May 30, 2013 17:22 troy
> To: TROY.LIU 劉春偉
> Cc: d...@apr.apache.org; modules-...@httpd.apache.org
> Subject: Re: apr_palloc is not thread safe
>
> TROY.LIU 劉春偉 <troy....@deltaww.com.cn> writes:
>
> >   In our practice, we found two threads get same address returned by
> >   apr_palloc. It will happen about one hour later after our server
> >   starts.  We are using apr 1.4.5, the issue still exists in the
> >   latest subversion.
>
> From apr_pools.h:
>
>  * Note that most operations on pools are not thread-safe: a single pool
>  * should only be accessed by a single thread at any given time. The one
>  * exception to this rule is creating a subpool of a given pool: one or
> more
>  * threads can safely create subpools at the same time that another thread
>  * accesses the parent pool.
>
> The pool system allows multiple threads to use multiple pools.  There is
> no point trying to make apr_palloc "thread-safe" as the API is not designed
> to work that way.  Even if apr_palloc was "thread-safe" how would
> apr_pool_clear work?
>
> A related discussion:
>
>
> http://mail-archives.apache.org/mod_mbox/apr-dev/201304.mbox/%3c792240597.462741.1366211671567.javamail.r...@brainsware.org%3E
>
> --
> Philip
>
> *************************************************************************
> This email message, including any attachments, is for the sole
> use of the intended recipient(s) and may contain confidential and
> privileged information. Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient, please
> contact the sender by reply e-mail and destroy all copies of the original
> message. [Delta Electronics, INC. China]
> *************************************************************************
>

Reply via email to