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,5ee499d03212eed3 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-10-08 12:07:41 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!sjcppf01.usenetserver.com!usenetserver.com!news-west.rr.com!lsnws01.we.mediaone.net!typhoon.san.rr.com!not-for-mail Message-ID: <3BC1F97E.6EA2F1E7@san.rr.com> From: Darren New Organization: Boxes! 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: Dynamic dispatch again References: <3BC1D39E.6EB86D43@san.rr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 08 Oct 2001 19:07:56 GMT NNTP-Posting-Host: 66.75.151.160 X-Complaints-To: abuse@rr.com X-Trace: typhoon.san.rr.com 1002568076 66.75.151.160 (Mon, 08 Oct 2001 12:07:56 PDT) NNTP-Posting-Date: Mon, 08 Oct 2001 12:07:56 PDT Xref: archiver1.google.com comp.lang.ada:13958 Date: 2001-10-08T19:07:56+00:00 List-Id: tmoran@acm.org wrote: > > >Because not all profiles will (for example) send a message as the first > >thing they do. > Ah. I thought the profile fixed the tasking structure. But it sounds > like the only required similarity in these tasks is that their spec > (list of "entry"s) is the same. All else is changeable, correct? Yes, ideally. Naturally, some limitations will exist, like initialization will always happen before finalization. But other than that, the ability to wait on multiple possible events at each point in the conversation is important to not rebuilding the whole queueing bit. > So as I understand it, you want to be able to do something like: > task type One is > entry a(i : in out integer); > entry b; > end task; > task type Two is > entry a(i : in out integer); > entry b; > end task; > ... > X : array() of tasks_one_or_two; > ... > select > X(i).b; > or > delay 1.0; > end select; > Is that it? Right. With the understanding that One is going to actually need an actual thread runnign when it's not in an entry, and wierdness in the middle (extra levels of indirection, extra tasks that just requeue, etc) are quite acceptable. Right now, my alternative is to package up every "entry" as an object of a tagged type and build a bidirectional queue of such things. Ugly. Especially since there will be bits of code in the dispatcher that do things like "ask each profile if it's ready to quit, and if any refuse, return that refusal, otherwise return ok." A real PITA to do if you have to queue a bunch of questions, then receive a bunch of answers, then compare the two lists, waiting for everyone to answer, etc. Been there, done that (in C), real ugly. :-) I thought with such sophisticated rendezvous built into Ada, it ought to be easier than that. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. Who is this Dr. Ibid anyway, and how does he know so much?