[omniORB] How to deleting an object derived from omni_thread and POA_MyObje ct

[Matej Kenda]

Thank you very much, Duncan.

We have currently moved the code that is executed in the thread to a friend
class of our servant. We will most probably revert the code to your
proposal.

Matej

-----Original Message-----
From: Duncan Grisby [mailto:dgrisby@uk.research.att.com] 
Sent: Monday, January 21, 2002 3:22 PM
To: Matej Kenda
Cc: omniORB-list (omniorb-list@uk.research.att.com)
Subject: Re: [omniORB] How to deleting an object derived from omni_thread
and POA_MyObje ct 


On Monday 14 January, Matej Kenda wrote:

[...]
> The object starts an initialisation thread when it is created 
> (run_undetached so that the object is not deleted after the execution 
> completes). This is done because the object factory may not be blocked 
> by the object initialisation in new, which can last for quite a long 
> time.
> 
> I have problems deactivating/deleting such an object. I can't use 
> join, because it wants to delete the object, but the POA is not happy 
> about that. On the other hand, deactivate_object can't be called 
> because ~omni_thread will complain (pthread's join is not called).

deactivate_object is only trying to delete the servant because the servant
class is derived from RefCountServantBase, and the POA holds the only
reference to the servant. If you don't use the RefCountServantBase mixin,
that won't happen.

I think the best way around your problem is to implement the servant
reference counting functions, _add_ref() and _remove_ref() yourself. Your
implementations should do the obvious reference counting (remember the
concurrency control!), but rather than deleting the object when its count
goes to zero, call join(). That will clear up the thread, and delete the
servant. That approach assumes that the thread is usually finished before
the servant is deactivated -- you don't want to block for a long time in
_remote_ref(). If that isn't suitable, you can do something else along the
same lines.

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --