Re: poa issue
- From: Owen Taylor <otaylor redhat com>
- To: orbit-list gnome org
- Cc: Michael Meeks <michael ximian com>,Elliot Lee <sopwith redhat com>
- Subject: Re: poa issue
- Date: 12 Jul 2001 10:02:46 -0400
Michael Meeks <firstname.lastname@example.org> writes:
> On Wed, 11 Jul 2001, Mark McLoughlin wrote:
> > The problem here is that we are finalizing the servant as it is
> > exectuing a request. If you read 184.108.40.206, you'll see that the poa is
> > not supposed to complete the object's deactivation until all requests
> > are completed.
> If we want to intelligently allocate the servant to be part of the
> BonoboObject [ so we can do fast, clever BonoboObject <-> Servant mappings
> ] how do we deallocate the thing without doing utterly evil delayed
> finalization hackery [ as in bonobo-1.0 ] etc. ?
s/utterly evil/utterly broken/.
> > The correct fix is not to call finalize at all, but let the
> > POA call it, which it does.
> I really dislike the coupling of the GObject lifecycle - with all
> the hacks that entails to the servant lifecycle. It means leaving this
> object around, that we know to be defunct - and beyond its useful life,
> and leaving it open to further method invocations [ such as redundant
> unrefs etc. ], and leaving potentialy large objects around in an ugly
When a call is in place on a object, it _is_ in use, and finalizing
it is just wrong.
Client A Client B
[ Refcount of b drops to zero,
b is finalized ]
b_servant->count++; [ segfault ]
If you want to live and die by refcounting, you can't
just ignore this refcount from a currently active call.
Unfortunately, in simple uses of the POA, there is no real distinction
between the reference for currently active calls -- which is a strong
reference, and entry in the active object map, which is a weak
One straightforward way around this is to use the ServantLocator
framework, maintain your own active object map, and call
bonobo_object_ref/unref() as calls come in an finish.
The main alternative I see to that is to play tricks on
bonobo_object_ref/unref() ... when your refcount goes
to 1, you know that the last remaining refcount to your
object is the reference count in the active object map.
You then call ->deactivate on the CORBA object.
If bonobo_object_ref() is called, you reactivate the object.
[ It's a little fuzzy to me whether this is allowed by
the POA spec, but I believe it is ]
If servant->finalize happens, the you can actually finalize
This is certainly messier, but something like this might
be needed for performance reasons.
But in any case, if finalization happens while a method
invocation on an object is under way, then the object was
finalized to early.
[ How do the proposals above relate to local short-ciruiting and
the fabled hope to make local calls #defines for vtable
accesses? Not very well, but if one wants to handle complicated
reentrancy the price is either real garbage collection or
a lot of refs/unref book-keeping. I don't think distributed
instability is an option. ]
] [Thread Prev