Re: Q: Stopping a task running a long simulation

[Adam Beneschan <adam@irvine.com>]

On Mar 11, 5:08 am, Gautier write-only <gautier_niou...@hotmail.com>
wrote:
> Hello,
> Being still a bit new to tasking, I have a question of how to
> terminate correctly a certain kind of task.
> I have a task type which is waiting for running a potentially long
> simulation; it is kind of a "daemon".
> (the rationale of using a task type is that I have several simulations
> that can be run in parallel, hence an array of these tasks).
> Now this simulation occurs within a GUI, where the user might want to
> stop it.
> Here is the task type I've defined:
>
>   task type Simulation_type is
>     entry Start;
>     entry Run( [some parameters] );
>     entry Stop;
>   end;
>
>   Simulation: array(PF_version) of Simulation_type;
>
>   task body Simulation_type is
>   begin
>     accept Start;
>     loop
>       select
>         accept Stop;
>         exit;
>       or
>         accept Run( [some parameters] ) do
>           -- some quick parameter passing
>         end Run;
>         Compute( [some parameters] );
>       or
>         delay 0.2; -- relax
>       end select;
>     end loop;
>   end Simulation_type;
>
> For aborting the simulation, I have tried this (happens when the main
> GUI window is destroyed):
>     for v in PF_version loop
>       abort Daemons.Simulation(v);
>     end loop;
> but (as expected if I've understood Barnes' chapter correctly), the
> task waits for 'Compute' to complete.
> At least, it is what happens with GNAT under Windows: despite the
> above, the GUI closes but the program somehow is still alive and CPU-
> busy.

I'm not sure you've understood correctly...or maybe I haven't
understood the problem correctly...  When the task is aborted, it
doesn't *need* to wait for Compute to complete.  The language leaves
it up to implementations to decide how quickly to abort, as long as
the abort happens at or before the next "abort completion point".
However, I'd be surprised by the behavior if you abort the task but
Compute keeps using CPU for any length of time.  I don't know GNAT
really well; maybe there are configuration options that you need to
select in order to get the more expected behavior.  In any case,
however, I know of nothing in the language that says that the task
must wait for Compute to complete before it aborts, unless Compute is
executing a very long abort-deferred operation, which seems unlikely
(see 9.8(9-11)---you didn't put the whole computation in a controlled
Initialize routine, I hope???).

Anyway, based on looking at the section on "abort completion
point" (9.8(15-19)), I suppose that if you can't get the behavior you
want with configuration options, you could do it by having Compute
perform a "delay 0.0" statement periodically.


> I have an alternative to that.
> 'Compute' has a generic 'Feedback' procedure for showing progress.
> I could with that way give a Boolean, user_abort, to 'Feedback', and
> 'Compute' would stop when an ad-hoc exception is raised, and return
> normally on its own.

You're saying Feedback would check something to see if another task
wants to abort it, and raise an exception if the answer is "yes"?  I'd
use a protected object for that (as opposed to a global Boolean
user_abort as you seem to be suggesting).  But I think this would work
and might be better than the "abort" meat-axe approach.

                                -- Adam