[omniORB] deleting active servants

[Carlos]

Pánczél Levente wrote:
> Hello!
> 
> 
>>It sounds like you are deleting a servant, and expecting to be able to
>>call deactivate_object in the servant's destructor. Are you?  That is
>>not permitted, since the POA is still holding a reference to the
>>servant. You should never delete a servant directly, but use the
>>servant reference counting provided by RefCountServantBase. That way,
>>you just call deactivate_object, and your servant is deleted when the
>>POA has finished with it.
> 
> 
> 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.

> This is not acceptable for me. See, I have terminal objects. They are servats to be remotely manageable. A terminal is incarnated az follows:
> 1. TermObj.so is dlopen-ed, and so its lock count is incremented, the library_handle will be saved into the terminal.
> 2. The entrypoint function is called, wich instatiates an object, and returns an interface (pure virtual base class) pointer to it, this increments an internal module_lock_count wich indicates when it is safe to close the shared object.
> 3. The RootPOA's reference is saved in the terminal.
> 4. The terminal's own Reference count is raised to 1 by being added to the list of local terminals.
> 5. A thread is created for the terminal, wich in first step activates the terminal object using the saved POA_ptr, and it saves the returned ObjectId
> 6. The thread finishes, and indicates termination. As a last step, it calls deactivate_object on the saved POA_ptr (RootPOA) with the saved ObjectId. (I don't think the POA registers the servant for deletion because of this, else I would get a lot of sigsegv-s in step 7 and 8 executed from another thread.)
> 7. A manager noticing the dieing terminal calls Terminal::Release() upon deleting it from the object list.
> 8. The point is that when the own reference count drops to 0 then:
> 8.1. TerminalRelease() makes a "delete this;" to ensure object deletion. (I would be glad if anyone told me, that the destructor runs and finishes BEFORE the "delete" returns.) The destructor frees associated resources.

No you can't do delete this because deactivate_object call the 
destructor of the object.

> 8.2. the module_lock_count is decremented by Terminal::Release() and if the module_lock_count happens to drop to 0, then the library_handle for the shared object file is returned by Terminal::Release() indicating that is should be dlclose-d. (It is my need that code outside the Terminal class closes the library, because I found that Linux was sometimes fast enough to close and _free_ the shared object from memory, while the last return statement of Terminal::Release() was about to be executed causing a sigsegv.)
> 9. Finished with the terminal.
> 
> Though I don't do such things, I don't understand why it is illegal to call deactivate_object from it's destructor.

Because deactivate_object calls the destructor of the servant.

> What am I doing wrong now? And could you suggest me a way to get rid of the servant in a fashion conforming with the ORB's operation, and also to have a chance to dlclose the shared object on time.
> 
> Thank you.
> Panczel, Levente
> 

I expect that this can help you.

Cheers.

Carlos.

> _______________________________________________
> omniORB-list mailing list
> omniORB-list at omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list
> 
>