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: 103376,41967527237c1aa2 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!proxad.net!news.in2p3.fr!in2p3.fr!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Fun with Tasking Date: Wed, 28 Mar 2007 17:17:52 -0500 Organization: Jacob's private Usenet server Message-ID: References: <1175097196.113031.259000@r56g2000hsd.googlegroups.com> <1175100948.580216.145940@r56g2000hsd.googlegroups.com> <1175104396.231171.125360@e65g2000hsc.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1175120180 12575 69.95.181.76 (28 Mar 2007 22:16:20 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 28 Mar 2007 22:16:20 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Xref: g2news1.google.com comp.lang.ada:14662 Date: 2007-03-28T17:17:52-05:00 List-Id: wrote in message news:1175104396.231171.125360@e65g2000hsc.googlegroups.com... ... > Thank you Adam. While making this sample program a sneaking suspicion > started to creep up that I really didn't know what I was doing, and > you helped verify that suspicion. What's really going on is I have a > number of tasks I'm going to run, and while themselves completely > independent of one another, they send updates to a single listening, > or collating, task. That is the task at the heart of my initial > post. My approach was to start up this collating task and give it's > pointer (or address) to the processing tasks. This works fine if the > collating task definition is in the acc_add_test procedure and the > Control_Block has a pointer to that task within it. However, I would > like the collating task definition to reside with the "exec" procedure/ > package as the sample has it. How would one declare and start up that > task, without any visibility into the package, just a procedure > pointer with a mode argument? My (terribly flawed) idea was the > PreProcess element of the procedure would set that up, but as you > pointed out, the procedure would never exit while the task is > running. So how to define the task and put it on "hold" until the > processing tasks can utilize it? I don't expect it's possible without > incurring as much ugliness as the program has already, but I thought > I'd give it a try. Thanks again =) I'm not going to try to figure out precisely what it is that you are trying to do (a listening task doesn't require anything special to listen!), but a couple of thoughts about trying to manage unrelated tasks with another task. (1) You really don't want to try to manage unrelated anything in Ada (Ada is strongly typed, after all). If you are using a very new compiler, probably the best way to relate some tasks that would otherwise be unrelated is to define them all to be derived from the same task interface. The idea is that you would put the control operations into the task interface, and then the manager would use access-to-interface'class to keep track of the tasks and call operations on them as needed. But you'll need a complete and non-buggy implementation of the entire Ada language, as amended; so far as I know only GNAT Pro even claims to support this. So you'd be better off trying to do this next year... Note that you have to start each task individually. The usual trick is to use a constructor function for that purpose. (2) Otherwise, I'd say that it can't be done reasonably. You could use Task-Ids to track the status of the tasks, but that won't help starting them. (3) Probably the best plan is to forget about having the management task interoperate directly with the other tasks. Rather, define an abstract tagged type (or interface, if you prefer) Processor, and have each package define any instance of that tagged type. It would have the needed management operations ("Start", "Status", "Stop", etc.), and again you would create an appropriate instance of each one (probably with the main program), and have the management task save a list of these as access-to-Processor'class, and manage them appropriately. The advantage of this technique is that you can wrap anything you need in these operations: if you need a conditional entry call, for instance, you would just implement one of those operations that way. (That's precisely how task interfaces get implemented anyway; you're just doing some of the work that the compiler would done.) Hope this helps. Randy.