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 09:26:07 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!nf3.bellglobal.com!sjcppf01.usenetserver.com!usenetserver.com!news-west.rr.com!lsnws01.we.mediaone.net!typhoon.san.rr.com!not-for-mail Message-ID: <3BC1D39E.6EB86D43@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: <3BC0FDB3.F185EDDF@san.rr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 08 Oct 2001 16:26:20 GMT NNTP-Posting-Host: 66.75.151.160 X-Complaints-To: abuse@rr.com X-Trace: typhoon.san.rr.com 1002558380 66.75.151.160 (Mon, 08 Oct 2001 09:26:20 PDT) NNTP-Posting-Date: Mon, 08 Oct 2001 09:26:20 PDT Xref: archiver1.google.com comp.lang.ada:13936 Date: 2001-10-08T16:26:20+00:00 List-Id: tmoran@acm.org wrote: > > >Here, I only get to have one piece of code per > >profile execute per message. I.e., now I only get one accept per unit. I > >can't do something like > >... > >I instead have to store the state and wait passively for a call to be made. > Huh? What's wrong with replacing the single changeable xlate with a > bunch of changeable accept's and other calls, eg: Because not all profiles will (for example) send a message as the first thing they do. For example, the way you have it coded, it will always call send_message after accepting a connection, and nothing I can put in a "profile" unit is going to change that. a profile might, for example, receive three messages, then send one and receive on in a loop, until it gets one that says it should receive three more. Just as an example. If I have only a single task, it has a fixed order for accepting messages in. Basically, I'm trying to build a state machine, but I have only a fixed number of states (the select or unary-accept statements) and a fixed number of transitions from each state. What you're offering is a way to do something different on each transition. I'm trying, instead, to actually have different transitions. In other words, I might want "profile_negate" to do something like accept first(...); loop select accept second(...) or accept third(...) if something_about_third_very_negate_specific then send_message(...) end if; end end while "profile_double" does something like accept first(...) send a message call an entry somewhere else end accept; accept second(...) -- not third accept second(...) accept second(...) accept third(...) Offering a method to replace only the bodies of the entries without replacing their structure is like saying "you can generate any executable code you want from the Ada grammar" when I'm asking for something like YACC. :-) Another thought I had was to have a "linking" task. It would just be a select in a loop, doing something like loop select accept first_left(i1 : in integer; o1 : out integer) do accept first_indication_right(i2 : out integer) do i2:=i1; end accept; accept first_response_right(o2 : in integer) do o1:=o2; end accept; end accept; or accept second_left(i7 : in integer) do accept second_right(i8 : out integer) do i8 := i7; end accept; end accept; end select; end loop; Then the side that would be originating the messages (the driver/dispatcher) would be able to call things like first_left(27, x); and where the profile would normally have "accept first_left(...)" it would have to have "first_indication_right(i); new_i := 2*i; first_response_right(new_i);" instead of the obvious accept mechanism. In other words, this would turn an entry call/accept into a pair of entry calls with a dispatcher in the middle matching them up. Seems horribly ugly, somehow. It also makes it impossible (I think) for a profile to wait on either of two entries becoming available. That is, it makes it impossible to say "accept messages, or stop if the `socket closed' or `user-abort' entries get called. Is there any way of saying "here's three entry calls, run whichever gets accepted first" from the caller's side, like there is from the server's side? Is there any way of having a requeue that requeues to a task type determined at runtime? Otherwise, I think I'm going to wind up building all kinds of ugly hand-rolled entry queues just to make it work. As bad as Java. Ick. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. Who is this Dr. Ibid anyway, and how does he know so much?