Re: Dynamic dispatch again

[Darren New <dnew@san.rr.com>]

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?