Re: poa issue

[Owen Taylor <otaylor redhat com>]

Michael Meeks <michael@ximian.com> writes:

> Mark,
> 
> 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 11.3.8.17, 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
> state.

When a call is in place on a object, it _is_ in use, and finalizing
it is just wrong.

 Just imagine:


    Client A             Client B
    --------             ---------

    b->foo()
                         b_servant->callback->invoke()
       b->unref()
                           [ 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
reference.

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.

Subsequently:

 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
   the GObjects.  

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.

Regards,
                                        Owen

[ 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. ]