Re: Problem with task component

[Adam Beneschan <adam@irvine.com>]

On Monday, September 24, 2012 1:23:50 AM UTC-7, Simon Wright wrote:

> What I wanted to do was to be able to write 'terminate' and to have the
> runtime realise that finalization of the object containing the task
> would be a good reason to take the terminate alternative[1].

> 
> [1] See, for example, the last three paras of John English's book ch19
> sec3,
> http://faculty.cs.wwu.edu/reedyc/AdaResources/bookhtml/ch19.htm#19.3
> 
>    This solution requires the master task to call Shutdown explicitly
>    when it wants to terminate the task. The disadvantage with this
>    approach is that it’s possible to forget to call Shutdown. A better
>    solution is to add a terminate alternative to the select statement:

I've been trying to think of a way to get around the "forget" problem by using controlled types.  My first thought was to define a controlled record (i.e. derived from Ada.Finalization.Limited_Controlled) that has a task as a component, and have the Finalize routine for the controlled type call the Shutdown entry.  That way, since the shutdown protocol would be defined, in essence, right by the definition of the task type, there's no way a procedure that uses the type could "forget" to call Shutdown.  No good, though; 7.6.1(4) says that the Finalize routine on the record object would be called *after* the task terminates.  So it would be too late.

A couple thoughts: (1) This isn't the first time I've seen a case where it would be useful for a task to be notified that someone wants to finalize it.  There have been several posts to c.l.a in the past by posters who tried Unchecked_Deallocation on an object containing a task, thinking it would shut down the task, and were surprised by the program's behavior.  I'm not convinced that it's a good idea to redefine "terminate" so that an attempt to finalize an object can cause an open terminate alternative to be selected; but, perhaps, it might be useful for a task to define an entry that is "bound" to a finalization attempt, so that if an object containing a task becomes eligible for finalization (i.e. the master on which it depends is being finalized, or an object that contains it is being deallocated), then that entry is called.  Or maybe there are other approaches.  But it does seem to me that this sort of functionality is one that could be useful but that the language makes it difficult to achieve.

(2) Off the top of my head, I don't see any *implementation* reason why a selective accept couldn't have both a delay alternative and a terminate alternative.  It seems like it wouldn't require the runtime library to do anything it doesn't already know how to do.

                        -- Adam