[omniORB] object deletion strategies

[Stefan Seefeld]

David Riddoch wrote:

> > It seems the POA will change this, i.e. there is *always*
> > an implied test for the object's validity. This would mean that
> > I can delete the object directly without the need to care how many
> > local references to it still exist (even local references are proxies...)
> > Is this interpretion right ?
> 
> Almost.  You cannot just go ahead and delete an object which is activated
> in the ORB -- since the ORB holds pointers to it.  You have to deactivate
> the object first (POA::deactivate_object), which is similar in spirit to
> _dispose() in 2.8.

Hmm. One important difference could be that it is possible to make the
POA::deactivate_object call synchronous, i.e. if the call returns, the object 
is known to be deleted. This seems possible since all invocations are either 
from within other threads, so the currenct thread can block on the deactivate 
call and wait for the other threads to finish, or they are serialized and to 
be executed from the same thread, in which case the ORB can check before each 
call and if the object has just been deleted the call is canceled.

The reason I'm going into these details is that we have currently dangling
references so a couple of objects never get destroyed (via _dispose). I'm
wondering whether I can just ignore this bug if it isn't going to show up with
the POA. It's kind of hard to figure out where the extra duplicate or missing
release comes from, I didn't find a good debugging strategy for this kind
of errors...

Regards,	Stefan
_______________________________________________________              
              
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: seefelds@magellan.umontreal.ca

_______________________________________________________

      ...ich hab' noch einen Koffer in Berlin...