[omniORB] deleting active servants

[Pánczél Levente]

Sorry, there's still something wrong. I get what you told me, but a question remains:
If I get it right, then the last operand executed from the code of my Terminal class is the RET at the end of its destructor. As I understand: POA "delete"-s the servant (wich is really a RefCountServantBase deriviate). So only the POA is to know, when it is sefe to dlclose the shared object file containing the code, but only my code knows how and wich handle is to be closed. Is there any way to integrate into the POA to customize the destruction of a servant?

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

If deactivate_object really called the destructor (I think you mean "deleted the object") then it would have done it in step 6, and all the actions of step 7 and 8 would result in a sigsegv. But they don't.
>
>> 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.
>
Maybe I have to take a closer look at the refcounts. If you're right then the only problem I can imagine is that the servant's inherited reference count never reaches 0, and thatswhy the POA never tries to delete it.