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,fd189a20f95495f3 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news3.google.com!feeder.news-service.com!feed.xsnews.nl!border-2.ams.xsnews.nl!feeder.news-service.com!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Task components, the rationale Date: Thu, 14 Jul 2011 11:23:07 +0200 Organization: cbb software GmbH Message-ID: <1eg7t9uxa15va.1wjt82hzzijnp$.dlg@40tude.net> References: Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: FbOMkhMtVLVmu7IwBnt1tw.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: g2news1.google.com comp.lang.ada:20200 Date: 2011-07-14T11:23:07+02:00 List-Id: On Wed, 13 Jul 2011 13:58:36 -0700 (PDT), Maciej Sobczak wrote: > On Jul 13, 8:52�pm, "Dmitry A. Kazakov" > wrote: > >> Now, if My_Worker started before completion of Initialize then this body >> >> � �task body Worker is >> � �begin >> � � � �Self.Foo; -- Boom! >> >> could call Foo of T or any of its derived type *before* Initialize, i.e. >> before the object's construction is done! That would be a much worse >> problem. > > I don't even think you need to introduce tasks to show the problem - > what if the component is of another controlled type? Yes, but the hack was made specifically for tasks. If anybody wished to have safe construction/destruction in presence of components spoiled by the Rosen's trick, he would need to postpone parts of constructors/destructors to arrange them in certain order. It guaranteed is impossible to do in certain cases. With task components that manifests itself as a deadlock. (I don't know if the problem is detectable through static analysis, but I doubt it is.) >> There is no simple solution for this. > > You have to just, you know, simply, introduce constructors to the > language. This is my pet feature for Ada 2020. :-) Well, constructors need to be properly crafted to handle this. Note that the problem is in inconsistencies at the typing level. Returning to the tasks, you have to properly attribute the task body. Is it a primitive operation? Is it class-wide? etc. Depending on that you should be able or not to dispatch from the body and that will determine the earliest stage of construction when the body is allowed to start and the latest point before it started. I think it would not be possible to do without class-wide constructors, e.g. ones constructing classes out of specific types. (This is a subproblem of a more general problem: dispatching upon construction/destruction.) >> To start with tasks must be >> inheritable from and their bodies must be primitive or class-wide >> operations, because aggregation (composition) + Rosen's trick is >> necessarily broken. > > It's not about tasks, it's about access discriminants to outer records > - they introduce circular references (outer has inner, inner knows > outer) and as such are evil. Yes. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de