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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,c33f8f65997c21d0 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.180.104.33 with SMTP id gb1mr142890wib.1.1348087242283; Wed, 19 Sep 2012 13:40:42 -0700 (PDT) Path: ed8ni3019173wib.0!nntp.google.com!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: Problem with task component Date: Wed, 19 Sep 2012 21:40:40 +0100 Organization: A noiseless patient Spider Message-ID: References: <1667b8e2qt7ei$.1gg1h3hrp9amz$.dlg@40tude.net> Mime-Version: 1.0 Injection-Info: mx04.eternal-september.org; posting-host="5f22ba276a4b4f77c63ae2949e7306f1"; logging-data="14049"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+H/z3qN8RDWYS2AsFPj5NqWrzmb9xKv9I=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (darwin) Cancel-Lock: sha1:GIueysHmbJWfZy6h/IEqQLkAEE8= sha1:ZGbuYuF/UtF7s6RdHLEkw2e53Uo= Content-Type: text/plain Date: 2012-09-19T21:40:40+01:00 List-Id: (Thanks also to Adam for helpful discussion) "Dmitry A. Kazakov" writes: > On Wed, 19 Sep 2012 19:22:07 +0100, Simon Wright wrote: > >> If a Limited_Controlled type has a component of a task type, is it >> wrong to call an entry of the task from Initialize? > > Right, this is mandated by 7.6(12), because the alternative is much > worse, in presence of class-wide access discriminant to the container, > which most people want. Not sure I need class-wide, will think about it. Thanks for the suggestion. > The simple rule is that you should never ever have task components > which you need to communicate to upon initialization and/or > finalization. > > Always use pointers to tasks. But doing so, you should be extremely > careful preventing dispatch in the task body during these > actions. Which is the rationale for 7.6(12). Also, it seems to me that if I don't use pointers I'm going to have trouble finalizing the object: the contained task is sitting there and prevents leaving the scope in which its containing object is declared, so the containing object doesn't get finalized and there's no opportunity for Finalize to tell the task to stop. (And wait until it's actually terminated before deallocating it. I know that AdaCore have fixed the feature where deallocating a task that hasn't yet terminated silently leaves the TCB allocated; does anyone know which FSF GCCs/GNATs this fix has made it into?)