Re: idiom for task termination?

[bobduff@world.std.com (Robert A Duff)]

In article <32FA10EF.32A@bix.com>, Tom Moran  <tmoran@bix.com> wrote:
>What's a good idiom for terminating tasks inside library packages?
>If I build a re-usable package which contains an internal task which
>has an 'entry quit' but does not have a select-terminate alternative,

Why not add a terminate alternative?  That's what it's for...

There are cases where terminate alts don't work.  E.g., if the task in
question is communicating with others via entry calls (perhaps to
protected objects), then you can't use a terminate alt.  But in your
case, the task must wait on Quit periodically, using an accept
statement.  So why not get rid of Quit, and use a terminate alt in this
case?

>I want to guarantee that it does in fact terminate even if the user's
>main program fails to call 'quit' (eg, dies on an unhandled exception).
>  I can declare type heartbeat_type is new
>ada.finalization.controlled...,
>make a finalize routine for it that calls my 'quit', and then tell the

Or simply abort the task.  Calling Quit may well be cleaner, though.

>user of my package that he should declare an object of this type in
>his main program.  I think that will work, but it requires rather
>more correct action on the part of the user of my re-usable package
>than I'd like to depend on.  If he puts his declaration in the wrong
>place, makes several such declarations, or skips it entirely, bad, and
>non-obvious, things could happen.
>  Any better techniques?

Well, if you have many such tasks, you could write a library package
that handles all of them.  Each package that declares a task would
register its termination action with this lib package, and the main
subprogram would call something that says "do all the termination
actions".  Then, the main subprogram just has to remember to call this
one procedure, rather than one for each such "reusable" library package.
I admit this doesn't completely solve the problem.

Note that your controlled object can't be declared in the library
package itself, since finalization happens *after* awaiting tasks.  As
you say, it needs to be one level more dynamically nested (i.e. in the
main subprogram).

Another idea, which may or may not work in your case, would be to
replace the task in question with a protected object.  Protected objects
go away "automatically", thus avoiding the issue.

- Bob