Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> writes:
> 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.
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
apr_pool_cleanup_null.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Received on 2012-11-19 13:03:51 CET