Re: Deallocating records with task type fields.

["Gene" <gene.ressler@gmail.com>]

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.