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. -- Stefan^2. -- Certified & Supported Apache Subversion Downloads: * http://www.wandisco.com/subversion/download *
