apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: [PATCH] Allow unrelated SMSes to reset
Date Wed, 18 Jul 2001 15:32:08 GMT
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


Mime
View raw message