Re: Tail recursion upon task destruction

["Egil Høvik" <egilhovik@hotmail.com>]

On Nov 18, 11:31 am, stefan-lu...@see-the.signature wrote:
> On Wed, 18 Nov 2009, Dmitry A. Kazakov wrote:
> > Now consider a case when the last screw is removed from the device. This
> > is an operation eventually serviced by the device driver. I.e. within
> > the device driver, you see, it was the last screw of the device and *if*
> > there is no other references to the device, it must fall apart. This is
> > a case where you wanted the device to commit suicide. There is nobody
> > else out there to do this. The device is dangling. This is not the only
> > use case, just one possible case.
>
> OK, so you have a task (a device) which notices that it is no longer
> useful. You would like such a task to do some cleanup and to commit
> "suicide". Unfortunately, it can't do the cleanup after the "suicide",
> because it is "dead" then. And it can't cleanup itself before being
> "dead" because it needs its local memory until the very moment of its
> "death".
>
> But couldn't you just use (or maybe abuse) the features from
> Ada.Task_Termination to do perform the cleanup, after the task has died?
> Even if it the "death" is not by suicide (apart from
> "suicide" = regular termination, the options are "murder" = abort and
> "accident" = unhandled exception).
> See <http://www.adaic.org/standards/05rat/html/Rat-5-2.html#I1150>.
>
> --
> ------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
>                Stefan dot Lucks at uni minus weimar dot de
> ------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------


This would still be a bounded error.
A task is not terminated until the task body has been finalized RM-9.3
(5),
and since Task_Termination handlers are executed as part of the
finalization
of task bodies RM-C.7.3(14/2), you would violate RM-13.11.2(11) by
deallocating
the task in the handler.

--
~egilhh