[omniORB] Please clarify behaviour of omniOrbPOA::deactivate_object (poa.cc - 1261)

[Martin B.]

Greetings!

I am slightly confused by the behaviour vs. the comment provided with 
the deactivate_object() function of omniORB.
The comment in poa.cc looks like this:

- - - - omniORB 4.1.2 / poa.cc, line 1260 - - - -
void
omniOrbPOA::deactivate_object(const PortableServer::ObjectId& oid)
{
   // Once an object is targeted for deactivation, things happen in
   // this order:
   //
   //  o wait for requests to complete
   //     -- note that new requests can arrive in the mean time, so the
   //        deactivation may never actually complete!  This is
   //        necessary to prevent deadlocks in objects which do
   //        re-entrant calls to themselves.
   //  o remove from active object map
   //  o etherealise
   //
   // It is not possible to reactivate the same object until the
   // etherealisation stage has happened. Attempts to do so are blocked
   // until it is safe to continue.
- - - -

The "note" confuses me, because from what I can see in the code, 
deactivate_object() will always and unconditionally call
   ...
   entry->setDeactivating();
   entry->removeFromOAObjList();
   ...
and then handle the waiting for outstanding requests separately.

This is also what I observe in my tests, namely that after I have called 
deactivate_object(), all new requests via any already existing object 
references will throw CORBA::OBJ_ADAPTER ( OBJ_ADAPTER_POAUnknownAdapter ).

Is this comment plain wrong, or do I misunderstand something about this?

cheers,
Martin