task abortion

task abortion

[tonyg]

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

Re: task abortion

[Dmitry A. Kazakov]

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?

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

Re: task abortion

[tonyg]

On Jan 25, 10:43 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> 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?
>
> 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. Kazakovhttp://www.dmitry-kazakov.de

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.

Re: task abortion

[Anh Vo]

On Jan 26, 1:12 am, tonyg <tonytheg...@gmail.com> wrote:
> On Jan 25, 10:43 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>
>
>
>
>
>
>
>
>
> > 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?
>
> > 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. Kazakovhttp://www.dmitry-kazakov.de
>
> 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.

Just in case your task disappear which I do not expect it will, you
can use package Ada.Task_Termination to query the reason (Normal,
Abnormal, Unhandled_Exception) it dies.

Anh Vo

Re: task abortion

[tonyg]

On Jan 26, 4:47 pm, Anh Vo <anhvofrc...@gmail.com> wrote:
> On Jan 26, 1:12 am, tonyg <tonytheg...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > On Jan 25, 10:43 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
>
> > > 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?
>
> > > 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. Kazakovhttp://www.dmitry-kazakov.de
>
> > 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.
>
> Just in case your task disappear which I do not expect it will, you
> can use package Ada.Task_Termination to query the reason (Normal,
> Abnormal, Unhandled_Exception) it dies.
>
> Anh Vo

Thabjs Anh for that