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,c33f8f65997c21d0 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.180.86.133 with SMTP id p5mr253130wiz.3.1348668762594; Wed, 26 Sep 2012 07:12:42 -0700 (PDT) X-FeedAbuse: http://nntpfeed.proxad.net/abuse.pl feeded by 88.191.116.97 Path: q11ni64680552wiw.1!nntp.google.com!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!nntpfeed.proxad.net!dedibox.gegeweb.org!gegeweb.eu!gegeweb.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Problem with task component Date: Wed, 26 Sep 2012 16:13:06 +0200 Organization: cbb software GmbH Message-ID: References: <1667b8e2qt7ei$.1gg1h3hrp9amz$.dlg@40tude.net> <187uk10m6z8xj.yr1cpbgrdur$.dlg@40tude.net> <1gq5enrpptnql.v7pdz1umht4a$.dlg@40tude.net> <19yadxsixu2y9$.1tfzkylgscckn$.dlg@40tude.net> <18te37e3kb1vq$.1bbagkhyd6aa1$.dlg@40tude.net> <5062ebb3$0$6583$9b4e6d93@newsspool3.arcor-online.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: FbOMkhMtVLVmu7IwBnt1tw.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: 2012-09-26T16:13:06+02:00 List-Id: On Wed, 26 Sep 2012 13:49:09 +0200, Georg Bauhaus wrote: > On 26.09.12 09:27, Dmitry A. Kazakov wrote: > >> The weakness of this approach is that the client must know its master. It >> is almost never the case. And it is tight coupling from the software design >> POV. > > But from the software design POV, the client, or its programmer, > always does know that there is an operational dependence if the client > should react to the master's life cycle. I don't understand why this > should not be made explicit? Because it is not same as to know who is the master. We have an example at hand: a task component. Who is the master? It could be any because the object can be instantiated anywhere. > Also, arguably, a master knowing the clients will create tight coupling > too, for it could otherwise be replaced with some other master. Master must know them at least in order to be able to spawn these tasks. The point is that bidirectional exchange between two tasks, e.g. when both calls entries of each other is a bad idea anyway you turn it. Good design always tries to have only unidirectional relationships. > task body Server is > Master_Task : M_CRef; > begin > accept Master (Master_Task : M_CRef) do Error-prone and does not work for task components anyway. What you indeed could do is to add a task attribute T'Master or equivalent to get the ID of the master and then to use it as: Is_Callable (T'Master); -- See Ada.Task.Identification I don't see how this is cleaner than more explicit constructs for querying if the task is wished to terminate. Anyway the problem is not much task termination but construction of class-wide objects. You want to communicate with a task component that dispatches on the container's tag upon container initialization and finalization. That is the core problem. (BTW, note bidirectional relationship: container -> task (component), task -> container (access discriminant), which expectedly causes troubles). -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de