On Mon, Nov 19, 2012 at 12:24 PM, Philip Martin
<philip.martin_at_wandisco.com>wrote:
> Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> writes:
>
> > As it turns out, your commit has only be the trigger but
> > not the root cause.
> >
> > serf_trunk/allocator.c, serf_bucket_allocator_create(), line 147:
> >
> > /* ### this implies buckets cannot cross a fork/exec. desirable?
> > *
> > * ### hmm. it probably also means that buckets cannot be AROUND
> > * ### during a fork/exec. the new process will try to clean them
> > * ### up and figure out there are unfreed blocks...
> > */
> > apr_pool_cleanup_register(pool, allocator,
> > allocator_cleanup, allocator_cleanup);
> >
> > Since we fork() for hooks, we can't use hooks in ra_local
> > while there is an open serf connection. Otherwise, we get
> > into trouble with pool cleanups:
>
> Does it ever make sense for the child process to run that handler? Is
> that to allow a parent process to allocate a serf connection and then
> fork off a child process to use the connection?
>
From the comments in APR/threadproc/unix/proc.c,
it seems that apr_proc_create runs *all* pool cleanups
in the child process to clean up duplicated file handles
and such.
-- Stefan^2.
--
Certified & Supported Apache Subversion Downloads:
*
http://www.wandisco.com/subversion/download
*
Received on 2012-11-19 12:29:38 CET