Who owns ForwardState?

From: Robert Collins <robertc@dont-contact.us>
Date: Sat, 02 Sep 2006 18:21:19 +1000

I realised today while looking at these bugs that one thing which is a
little unclear is who 'owns' a number of our objects.

Refcounting is important when there are multiple owners - but I think it
will clarify our code if we say who 'should' own objects:

I.e. FwdState -

who owns it?

Right now, its owned by itself, and by the Server modules.

The self-owner hack [which I think I introduced in another module] is in
hindsight not all that good - it would be better for the thing that
knowns when a FwdState is needed, and is not needed, to own that key
reference.

In our case, right now, theres a number of owners asnState,
ClientReplyContext, ServerState.

I think though, that we can 'simply' identify the right owners as
'things that desire connections via the forward infrastructure.

I.e. asnState, and the Store should be owners, and thats it.

So why does ServerState own a reference ? AFAICT its to allow it to call
into the FwdState, so we have the situation where
FwdState <-> ServerState
- an object reference.

I think, on balance, that modules which are called from other modules,
should only hold weak references - cbdata'd references back into them.
That way, theres no object loops, and naïve refcounting should work
well.

This would mean that object would be holding long lived cbdata
references, not just call-to-call, but we already have that and I think
its fine.

Request abortion when we decide not to finish, would in this scenario
cause FwdState to cleanup and be destroyed, and the ServerState would
then see it as having invalid cbdata handles, so would wind up in
whatever manner it chooses too - probably by:
 * deciding if the connection can be reused
 * if it can reuse, do whatever is needed to reset it for use
 * if not, do a TCP_RST on it.

If we chose to finish a download into the store on client abort, the
FwdState would be kept alive by the store, which is now owning it, and
the Server module would be unaware.

Thoughts so far?

We could start transitioning to this by:
 * guard all the calls to the FwdState from the Server with a check for
cbdataValid,
 * switch to a cbdata handle from the RefCount on in ServerState

-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.

Received on Sat Sep 02 2006 - 02:21:48 MDT

This archive was generated by hypermail pre-2.1.9 : Sun Oct 01 2006 - 12:00:06 MDT