Philip Martin <philip.martin_at_wandisco.com> writes:
> Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> writes:
>> On Mon, Nov 19, 2012 at 12:24 PM, Philip Martin
>>> 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?
If the processes were behaving like that the child cleanup handlers
would not be involved.
>> 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.
> apr_proc_create runs the child cleanup handlers. Note that two handlers
> are passed to _register, one for the parent one for the child. I'm
> asking why serf installs a child handler rather than passing
The cleanup handler is just releasing memory via apr_allocator_free. I
see no reason for it to be installed as a child cleanup handler.
Certified & Supported Apache Subversion Downloads:
Received on 2012-11-19 14:45:34 CET