Re: Class with task destructor

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

On Tue, 29 Nov 2011 18:21:51 -0800 (PST), Adam Beneschan wrote:

> The problem with waiting on the Finish entry of the task, as you
> attempted to do in your next post, is that it may create a race
> condition.  After the rendezvous is completed, there still may be some
> delay between the time the task finishes the ACCEPT and the time it
> actually terminates, and that still makes it possible that the caller
> could try to free the task before it has actually terminated (which is
> a bounded error according to the RM).  I don't know of a good way
> around this (besides Ada.Task_Termination).

I am using polling for T'Terminated after the rendezvous.

However I have an impression that it should be safe to call
Unchecked_Deallocation in GNAT prematurely.

> Maybe there are some
> missing features in the language,

Not a feature, rather a plain language design bug. Unchecked_Deallocation
shall wait for the object's finalization. Finalization of a task evidently
includes its termination. So Unchecked_Deallocation must block until
termination before it frees anything.

> such as (for instance) a TERMINATE
> statement that can be used inside an ACCEPT statement that causes the
> task to terminate, completes the rendezvous, and guarantees that when
> the calling task is unblocked, the called task will be terminated.

As for missing features, rather than the Task_Termination hack, there
should be some way for the task to communicate to its master upon
completion, e.g. a rendezvous. A handler has a disadvantage of being a
protected procedure.

Furthermore, if the master does not accept such a notification from a
failed slave, the exceptional state should somehow propagate into the
master. I didn't think about the details, but the language design is unsafe
here.

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