[omniORB] deleting active servants

[Pánczél Levente]

Hi!

If I get it right, you suggest that I override _remove_ref(). I could really do that. Suppose I override _remove_ref() to call dlclose() on the shared object file's handle if it notices that the object being currently deallocated is the last instance. This way I would end up in a_remove_ref() calling dlclose() as its last command. As I see, the call to dlclose() detaches the file's memory image from the process' address space, causing the next statement after dlclose() to segfault. The mentioned "next statement" exists, 'cos the } closing the _remove_ref() definition generates an ASM RET, which will be deallocated after a call to dlclose().
The best solution would be if POA had a hook, _through_ wich the _remove_ref() or anything like it would be called.

for example if in the POA's code every 
object->_remove_ref()
would be changed to a call like
ReferenceRemoverHook(object);
where ReferenceRemoverHook would be a function pointer in the POA, initialized to a function only performing the former call to _remove_ref().

Isn't there a mechanism like this?
'Cos I'm sure, if the answer is no, then the object-destruction-triggered closing of shared objects (DLLs) on concurrent systems involves a large amount of synchronization.

Cheers
Panczel, Levente

-----Original Message-----
From:	Duncan Grisby [mailto:duncan at grisby.org]
Sent:	Fri 2003-12-05 18:24
To:	Carlos
Cc:	Pánczél Levente; OmniORB support
Subject:	Re: [omniORB] deleting active servants 
On Wednesday 3 December, Carlos wrote:

> Pánczél Levente wrote:

> > Thanks Duncan! Though I really read that in the documentation, I
> > forgot about it. So if I understand right, I have to do the
> > following:
> > The POA's reference is held by the object. When I need the object
> > to be deleted, I simply call POA::deactivate_object() and that
> > releases both the POA and the servant?
> 
> No, deactivate_object only calls the destructor of the servant.

No it doesn't!  deactivate_object calls _remove_ref on the servant.
If the implementation of _remove_ref so decides, _that_ deletes the
servant.

Most importantly, deactivate_object does not always call _remove_ref
immediately; in many cases, that happens some time after
deactivate_object returns.

It sounds to me like you can get the behaviour you want by
implementing your own reference counting functions, rather than using
RefCountServantBase. That will allow you to know exactly when your
servant is deleted (since it will be your code that does the
deletion), and thus do whatever else is required at that time.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --