Re: poa issue

[Michael Meeks <michael ximian com>]

Hi Owen,

        Thanks for your mail, I was hoping to grapple with this today
and solve it and your comments are helpful.

On 12 Jul 2001, Owen Taylor wrote:
> > how do we deallocate the thing without doing utterly evil delayed
> > finalization hackery [ as in bonobo-1.0 ] etc. ?
>
>  s/utterly evil/utterly broken/.

        Yes - it's really not pleasant, and was not well thought
through - the client API of BonoboXObject is however very good, and
made it worthwhile IMHO ( for the user at least 8).

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

        This is the issue we have currently, of course - ideally we
would like the CORBA_Object / servant to be a GObject - so we could
use the same ref-count and not have an issue; not an option yet
though.

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

        I like this approach, I think I'll code this up shortly.

> 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 ]
  
        This won't happen, since it appears that we will not have a
threaded ORB wrt. to processing multiple incoming requests
concurrently, so not a big issue - since it should be truly finalized
& de-registered by the ORB by the time the invocation completes.

>  If servant->finalize happens, the you can actually finalize
>    the GObjects.

        Yes.

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

        Quite - the problem in a nutshell.
 
> [ 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. ]

        Well - the thing is :-) in-proc there is no need for the ref
counting, consequently there won't be an extra ref on the servant [
since this is taken only on the remote route ] and thus when the
object is deactivated the servant finalization will occur. Thus should
be no problem ( I hope ).

        Anyway, now to hack it up and find the interesting corner cases.
  
        Thanks again,

                Michael.

-- 
 mmeeks@gnu.org  <><, Pseudo Engineer, itinerant idiot