Re: Task origin track from a class

[Shark8 <onewingedshark@gmail.com>]

On Jul 13, 2:41 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Tue, 12 Jul 2011 17:36:29 -0700 (PDT), Shark8 wrote:
> > On Jul 12, 5:31 am, Simon Wright <si...@pushface.org> wrote:
> >> Simon Wright <si...@pushface.org> writes:
> >>> "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> writes:
>
> >>>> So the unfortunate rule of the thumb is: never use task components,
> >>>> but access to task instead. From Finalize you would call Stop entry or
> >>>> an equivalent and then free the task object using
> >>>> Unchecked_Deallocation.
>
> >>> With GNAT, best not to free the task object until 'Terminated is True
> >>> (GNAT's I have used would silently fail to actually free the TCB!
> >>> resulting in an insidious memory leak).
>
> >> Oops, I forgot to add that I'd aborted the task first (as Dmitry said,
> >> it's not always possible to arrange a clean shutdown).
>
> > Hm, would it be a usable idea for say the memory manager for an OS,
> > such that the requests to the manager from programs (and perhaps even
> > compilers) are delegated to the task; after all you don't want to shut
> > the memory-manager down (terminate the task) at any point in normal
> > operation.
>
> The issue has nothing to do with memory management.

You misunderstand me; I was asking that if it's generally impossible
to destroy such a construct then would the use of such a construct be
allowable (or desirable) in the cases where the destruction of such
construct is itself generally undesirable/invalid.

> The actual problems
> are:
>
> 1. The procedure of destruction of the objects having task components.
> Tasks are completed *before* Finalize is called.

Shouldn't they be completed before Finalization of the object?
And, if they are still running, shouldn't a finalize force termination?