Philip Martin <philip.mar...@wandisco.com> writes: > Stefan Fuhrmann <stefan.fuhrm...@wandisco.com> writes: > >> On Mon, Nov 19, 2012 at 12:24 PM, Philip Martin >> <philip.mar...@wandisco.com>wrote: >> >>> Stefan Fuhrmann <stefan.fuhrm...@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 > apr_pool_cleanup_null. 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: http://www.wandisco.com/subversion/download
