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-09 08:40:05 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!netnews.com!xfer02.netnews.com!newsfeed1.cidera.com!Cidera!sjcppf01.usenetserver.com!usenetserver.com!news-west.rr.com!lsnws01.we.mediaone.net!typhoon.san.rr.com!not-for-mail Message-ID: <3BC31A54.F33F03D1@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: <3BC2475D.535D4E72@san.rr.com> <6Nuw7.17802$IY3.12247494@news1.rdc1.sfba.home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 09 Oct 2001 15:40:19 GMT NNTP-Posting-Host: 66.75.151.160 X-Complaints-To: abuse@rr.com X-Trace: typhoon.san.rr.com 1002642019 66.75.151.160 (Tue, 09 Oct 2001 08:40:19 PDT) NNTP-Posting-Date: Tue, 09 Oct 2001 08:40:19 PDT Xref: archiver1.google.com comp.lang.ada:14039 Date: 2001-10-09T15:40:19+00:00 List-Id: tmoran@acm.org wrote: > > >approach to dynamically dispatching an entry to one of N different tasks > If the bodies of the tasks are too heterogeneous, how about the calls > on the tasks. Are there a small number of subroutines A, B, and C that > do all the calls? Could you make an A that calls task One, and another > A that is identical except that it replaces all references to One with > references to Two, and so forth. Then use overloading to tell which A > is being used. Or have a tagged type determine dynamically which A is > to be used, and thus implicitly which task is to be called. Basically, what it sounds like you're suggesting is that I wrap the entry statements inside the polymorphic calls. That is, rather than accept xxx(...) do t.xxx(...) -- polymorphic dispatch end accept; I think you're suggesting I do procedure t.xxx(...) is -- polymorphic dispatch with xxx(...) -- call the entry for this particular task end xxx; I think that's what I'm going to wind up having to do. Basically, I was trying to avoid having to say things like "this routine should not block", but rather deal with it with event queuing, selective accept, and so on. However, it looks like I'm going to have to build a tagged type and rely on the programmer building in calls to entries or instantiating queues and such as appropriate. I was hoping to put all this infrastructure in the library so it would be easier to construct a configuration. Le sigh. :-) There are about 30 routines that need to be dynamically dispatched. In addition to those 30 primitives, there are a number of primitives that I would want to layer on top that I'd been hoping to build as tasks that map the original primitives into the same set of primitives. For example, a task that would receive each fragment of the message until all fragments had arrived, concatenate them, and present them as if they arrived in one chunk, or a task that would accept a message, blocking the caller until it had actually been put on the wire, etc. I can probably do these with protected objects or so, but again I expect I'll wind up running into problems with specs and implementations tied too tightly. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. Who is this Dr. Ibid anyway, and how does he know so much?