From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,3cfaa627fc3366de X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news3.google.com!feeder.news-service.com!94.75.214.39.MISMATCH!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Task origin track from a class Date: Wed, 13 Jul 2011 19:22:50 +0200 Organization: cbb software GmbH Message-ID: <1kklrhcrotwie.1nkv97txvt482.dlg@40tude.net> References: <4o0rnqqqec1s$.19h46xsbjbku2.dlg@40tude.net> <024dd037-7c8f-460a-8ec4-0bf2456435ee@fq4g2000vbb.googlegroups.com> <13h82glc3htf0.1sjzw91gfndbf$.dlg@40tude.net> <3790e1e7-ab81-47a0-8d21-e9dda147d905@n5g2000yqh.googlegroups.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: 0gEzX7xNyz7xAL3b4pbLjA.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: g2news2.google.com comp.lang.ada:21166 Date: 2011-07-13T19:22:50+02:00 List-Id: On Wed, 13 Jul 2011 09:31:47 -0700 (PDT), Shark8 wrote: > On Jul 13, 2:41�am, "Dmitry A. Kazakov" > wrote: >> On Tue, 12 Jul 2011 17:36:29 -0700 (PDT), Shark8 wrote: >>> On Jul 12, 5:31�am, Simon Wright wrote: >>>> Simon Wright writes: >>>>> "Dmitry A. Kazakov" 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. It is possible, the requirement, as I said, is an open terminate alternative. >> 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? Yes, the question is at which part of finalization. Finalization is a complex action. BTW, it is not just Finalize. If you considered to pass some parameters to a task component, you cannot do it from Initialize. The following does *not* work: task type Worker is entry Start (Text : String); end Worker; type T is new Ada.Finalization.Limited_Controlled with record My_Task : Worker; end record; overriding procedure Initialize (Object : in out T); task body Worker is begin accept Start (Text : String) do Ada.Text_IO.Put_Line (Text); end Start; end Worker; procedure Initialize (Object : in out T) is begin Object.My_Task.Start ("Hey"); -- Beware, it will hang! end Initialize; This is not a compiler bug, it is a mandated behavior. > And, if they are still running, shouldn't a finalize force termination? You cannot force task termination because the tasking model is cooperative. In particular you should never use the abort statement unless the task was carefully designed to be abortable. It should not allocate any resources which might get lost upon a preemptive task termination. One way to make a task abortable is to have a controlled object of which Finalize does the cleanup: task Abortable is Resources : Controlled_Object; begin loop ... end loop; end Abortable; when Aboortable is aborted the Resources' Finalize will be called so that you could do the necessary cleanup before the task dies. Note that Finalize is abort-deferred, it means that you cannot abort a Finalize (when Finalize is called as a part of finalization), it must complete first. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de