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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6009c73a58f787a0 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-01-15 16:56:22 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!news.gtei.net!newsfeed1.cidera.com!Cidera!cyclone.socal.rr.com!cyclone3.kc.rr.com!news3.kc.rr.com!typhoon.san.rr.com!not-for-mail Message-ID: <3C44CFBD.BC1ED52F@san.rr.com> From: Darren New X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: How to avoid unreferenced objects (mutexes etc) References: <3c3ee8c8.105408250@News.CIS.DFN.DE> <3c429d1c.2624281@News.CIS.DFN.DE> <3C445F34.44697AEF@san.rr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 16 Jan 2002 00:57:12 GMT NNTP-Posting-Host: 66.75.151.160 X-Complaints-To: abuse@rr.com X-Trace: typhoon.san.rr.com 1011142632 66.75.151.160 (Tue, 15 Jan 2002 16:57:12 PST) NNTP-Posting-Date: Tue, 15 Jan 2002 16:57:12 PST Organization: Road Runner Xref: archiver1.google.com comp.lang.ada:18953 Date: 2002-01-16T00:57:12+00:00 List-Id: Matthew Heaney wrote: > > "Darren New" wrote in message > news:3C445F34.44697AEF@san.rr.com... > > Matthew Heaney wrote: > > > Now you're free to derive types from T, and bind derived type instances > to > > > a task. Using this idiom obviates the need for extensible task types. > > > > Not really, because there are various operations that may only be > > applied to entries, and various operations that may only appear in task > > bodies and hence your T and its derived types cannot affect it. > > But won't this work: > > package P is > type T is abstract tagged limited private; > procedure Op (O : in out T) is abstract; > private > task type T_Task_Type (O : access T) is > entry E; > end T_Task_Type; > > type T is abstract tagged limited record > T_Task : T_Task_Type (T'Access); > end record; > > end P; > > Now each instance of T gets its own thread. Types in T'Class have > visibility to the task object (assuming they are declared in children of P). Sure. Now Op can't act as an entry. The basic problem is that if I have something that says x.boop and boop is an entry, it can only call one specific piece of code. That one specific piece of code has to be the one that determines whether the code blocks. > > As an example, if your task is coded without any guards on the entries, > > there's no way for a child of T to add a guard. > > But couldn't a derived type NT extend T to include a protected object (that > implements a semaphore, say), that could be used by types in NT'Class to do > the same thing? That's not guarding an entry. If T.op dispatches, then it can't be an entry. If it's an entry, I can't override it. I can't do select T.op or delay 10.0 ; yadda end select; and have T.op be one of two different pieces of code, for example. The problem I had was trying to build a library wherein the framework instantiates a number of tasks. Each task is provided by the user of the framework. (Think, for example, of someone writing multiple types of windows in a GUI framework.) Each task would need to respond to different events at different times (meaning selective accepts in the tasks) and the framework wanted to not have to know what all these different task types are (meaning dispatching). Couldn't figure out how to do it properly. Wound up building a kludge that basically involved manually marshalling all the messages and queueing them, and generally reimplementing the entry queue mechanism in Ada. > I haven't found a need for extensible tasks. I have, but then that's the kind of software I write. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. The opposite of always is sometimes. The opposite of never is sometimes.