Re: Deallocating records with task type fields.

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 10 Dec 2005 20:06:46 -0800, Gene wrote:

> Many thanks.  I certainly could have picked a better of example that
> Port for data.
> 
> In fact the real environment record also has a protected output queue
> with procedures to get data from the queue that the Listener has placed
> there.  That's the interesting case because other tasks need to call
> functions that can touch the queue.  I couldn't see a good way to
> declare the queue on the task stack and yet allow other tasks to get
> things from it.
> 
> So before the current method I indeed implemented the shared queue by
> passing it to the Listener with a discriminant (your 2.). Also tried a
> Start entry (your 3.).  In all the method above is by far the cleanest
> because the whole Listener is a single type that acts like a functional
> closure.  This matter of handling deallocation when the executive task
> exits is the only rough edge.
> 
> As the name implies, the application is a TCP network listener in a
> multi-node graphics application.  Listeners are allocated as needed and
> exit when their corresponding connections are terminated, either
> normally or due to an error condition.  When this happens, we want the
> Listener to arrange for its own deallocation.
> 
> Currently I just have the Executive put its enclosing Listener on a
> system-wide "dead listener" queue.  There is a procedure that traverses
> the queue to deallocate any listeners whose executive tasks have indeed
> terminated.  This is called whenever a new Listener is allocated.  This
> works fine (although it needs Real Time Extensions).  I wondered if
> there was a simpler way.
> 
> In fact just for fun I also tried having the Listener call
> Unchecked_Deallocation itself just before exiting (i.e. the task was
> deallocating its own context!).  And with GNAT running under both
> Solaris and Windows it never caused a problem.

Yes, AFAIK it works with GNAT.

But the real question is if a listener can be accessed outside the task,
then there is a danger that the task could prematurely deallocate it. Thus
there must be somebody responsible for the life span of listener. Your
variant with "dead listener" queue is nothing but a GC. One could also use
reference counting GC. In any case it is global GC, which is responsible.
The problem with this is what is a listener object worth when the task is
dead? If a task life span is shorter then this state change should be
visible for users of listeners. This devaluates the idea of GC. If users
are aware of state change, they could also take care of deallocation of
listeners.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de