On Wed, Jul 18, 2001 at 05:30:17PM +0200, Sander Striker wrote: > > > can you guarantee that the registration and destruction of the > > > sms, via cleanup, will not stuff the parent by effectively > > > destroying the child sms twice? > > > > Yup. That's the catch. It'd probably need to be a bit more > > sophisticated than what I've posted OR make the apr_sms_reset a bit more > > robust (i.e. handle SMSes that have already been cleaned up). I'm > > leaning towards making the apr_sms_reset more robust. -- justin > > I wonder how you plan on doing that. > > Furthermore, the method of registering the cleanup with an > unrelated sms(B) will not work if the registering sms(A) > is destroyed before the cleanup is run in B. In other > words, if A is destroyed the cleanup is still registered > in B. If B is reset/destroyed: boom. > Or maybe you were planning to unregister the function when > the thread exits (in which case it would probably work).
Ideally, it could do that. Add another cleanup in B that calls unregister on A. That's work, right? Even if we are being called from A to cleanup? And that fixes the mess of what happens when B dies before A does. Otherwise, something similar to what Dean Gaudet posted yesterday with the refcount of 2 might work as well. > I'd opt for making the registration a bit more sophisticated. > A simple check for ancestry should be enough. At least in our use case, ancestry should never occur. But, in the general case, it very well might. -- justin
