Re: task abortion

[tonyg <tonythegair@gmail.com>]

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