Re: Class with task destructor

[Simon Wright <simon@pushface.org>]

Adam Beneschan <adam@irvine.com> writes:

> On Nov 30, 12:35 am, Simon Wright <si...@pushface.org> wrote:
>> "Rego, P." <pvr...@gmail.com> writes:
>> >> You ought to wait until the task has terminated before freeing it.
>>
>> > How could I wait for the task termination?
>> > Could be something like
>>
>> >    procedure Destruct (T : access Test_Class) is
>> >       T_Ptr : Test_Class_Ptr := Test_Class_Ptr (T);
>> >    begin
>> >       T.Primary.Finish;
>> >       DelayUntilTaskTermination (T_Ptr.Primary);
>> >       Free (T_Ptr);
>> >    end Destruct;
>>
>> > ? But is there some package with something like it?
>>
>>    while not T_Ptr.Primary'Terminated loop
>>       delay 0.001;
>>    end loop;
>
> Is it just me, or are there others who think that resorting to code
> like this is ... well, icky?

This was an answer to the specific question.

In the context where I used this scheme, it would have been completely
inappropriate to have an unbounded loop like this in the main context;
so the actual delay and Unchecked_Deallocation was handed over to a
low-priority housekeeping task. To do this required cooperation from the
code generator; altogether too complex to go into here! (and I'm by no
means sure that the design is the best possible).

I think I'd be concerned if an implementation arranged to do this sort
of thing 'under the hood'. How would it know what would be an
appropriate 'lower priority', for example?

I'm not sure that the code above is actually icky. You might think that
the aspects of the language that force you to do this are icky; but I
think it's quite reasonable. I'd be even happier if a program that tried
to deallocate an unterminated task was *required* to receive
Tasking_Error or Program_Error; that way we'd have to do something about
it.