Mladen Turk wrote:
Hi,
The current APR pool implementation destroys all child pools
before doing actual cleanup of registered objects.
I propose that we add the option that would mark the child pool
to be destroyed after all objects for that pool has been
destroyed.
Right now what we have on pool destroy/cleanup is:
1. destroy all child pools
2. call registered cleanups
I propose we extend that to:
1. destroy all child pools *not* marked as 'dormant'
2. call registered cleanups
3. destroy all child pools marked as 'dormant'
Here is the reason why we'd need something like that:
create P1 from global pool
create object O1 from P1
do forever {
create pool P2 from P1
create object O2 dependent on O1
try {
do something with O2
destroy P2
} catch on O2 error
report the error
destroy P2
}
}
Now, this works perfectly in a single thread environment,
but in case the O1 can be destroyed while O2 is in the 'do something
with O2'
we would have a core dump because O2 would fail (because its work
will be interrupted by the O1 cleanup) and P2 will already
be destroyed (P2 destroy was called by the P1 cleanup).
In case we could declare P2 as 'dormant' of P1 the 'destroy P2' would
not cause the core dump, because it would not be destroyed in advance.
Any comments?
I don't believe you can solve such cases in the way you propose -- *in
general* -- without some kind of synchronisation between the thread that
owns P1 and the one that owns P2.
You can solve this particular case with pool cleanups the way they are
now -- just register a P2 cleanup keyed to O2 that either waits until O2
is done, or aborts whatever O2 is doing. At the point when that cleanup
runs, P2, O2, P1 and O1 are all valid.
