Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
task abortion
18 views
Skip to first unread message
tonyg
Jan 25, 2012, 5:11:55 AM1/25/12
to
I want to be able to abort a task if it has not responded for a while,
and then start a new one in its stead.
I have a pointer going to the concerned task.
Each task has a 'stop accept' in its rendezvous which forces it out of
its loop so that it ends, but if the task has frozen for some reason
then I want to abort.
I would be interested how to do this and folks strategies for keeping
on top of tasks
Dmitry A. Kazakov
Jan 25, 2012, 5:43:14 AM1/25/12
to
On Wed, 25 Jan 2012 02:11:55 -0800 (PST), tonyg wrote:
> I want to be able to abort a task if it has not responded for a while,
> and then start a new one in its stead.
>
> I have a pointer going to the concerned task.
>
> Each task has a 'stop accept' in its rendezvous which forces it out of
> its loop so that it ends, but if the task has frozen for some reason
> then I want to abort.
What are you going to achieve by that?
> I want to be able to abort a task if it has not responded for a while,
> and then start a new one in its stead.
>
> I have a pointer going to the concerned task.
>
> Each task has a 'stop accept' in its rendezvous which forces it out of
> its loop so that it ends, but if the task has frozen for some reason
> then I want to abort.
Consider the scenarios:
1. The task crashed, it is already terminated then.
2. The task is looping somewhere:
2.a. What about the resources it owns? Local resources are usually freed
when the task is aborted. But if you have some globally allocated memory,
semaphores etc, they all get lost unless freed by some local controlled
objects, "holders" releasing the resources upon finalization, as they leave
the scope upon task abort. Now:
2.b. What if the task is frozen in an abort-deferred thing? Finalization is
such a thing. Abort-deferred stuff cannot be aborted. Note that system I/O
is most likely non-abortable. I.e. you would not be able to abort
Ada.Text_IO.Get_Line or recv on a socket etc anyway.
All in one, aborting tasks doing complex stuff is not likely to work in a
reasonable way. Aborting tasks doing simple stuff is not needed, such tasks
impose no problems anyway. Ergo, it is not likely you would need to abort
any task.
If you decided for aborting, you would have to redesign almost everything
and in an extremely careful way in order to make tasks logically abortable.
That means to make continuation possible and meaningful after aborting some
tasks. Now a guess: making the tasks right and thus preventing a need
aborting them, would probably be far less efforts...
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
tonyg
Jan 26, 2012, 4:12:56 AM1/26/12
to
On Jan 25, 10:43 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
Since I wrote my message I have discovered the package
Ada.Task_Identification. I totally agree with your argument on not
having them fail in the first place. My strategy should be then not to
abort :), I'm going to use that package just to monitor my tasks and
see if any freeze for some IO reason. Thanks for the advice.
wrote:
Ada.Task_Identification. I totally agree with your argument on not
having them fail in the first place. My strategy should be then not to
abort :), I'm going to use that package just to monitor my tasks and
see if any freeze for some IO reason. Thanks for the advice.
Anh Vo
Jan 26, 2012, 11:47:16 AM1/26/12
to
can use package Ada.Task_Termination to query the reason (Normal,
Abnormal, Unhandled_Exception) it dies.
Anh Vo
tonyg
Jan 31, 2012, 8:25:46 AM1/31/12
to
0 new messages