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? >> > > 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
