Re: Dynamic dispatch again

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

tmoran@acm.org wrote:
> 
> >OK, I'm still trying to figure out how to make one entry call wind up
> >calling code in different units.
> >...
> >Essentially, I have a basic manager task doing I/O, distributing
> >messages to "profiles". Each "profile" can get the same set of messages
> >(start, stop, are you ready, here's a message), but each responds to the
> >messages in different ways.
> 
> How about having a single "profile" task, and using tagged type "methods"
> to respond in different ways, eg:

I thought about this. The problem is that profiles are basically
implementing protocols. 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

begin
  accept initialize(params : in ...; ready : out boolean) do
    ...
  end accept;
  accept connection(params : ...) do
    -- set up connection
  end accept;
  send_message(...); -- peer receiving open is first to send message
  accept recv_message(...) do
    -- Process first answer
  end accept;
  stick_in_database(...);
  accept recv_message(...) do
    -- Process second answer
  end accept;
  ...
end;

I instead have to store the state and wait passively for a call to be
made. At this point, I might as well use a protected object, since I
still don't have a thread running in my code.

It would be very difficult, for example, to have the "are you ready to
start?" question answered "yes", followed immediately by starting to do
something. On the other hand, if I could get different entries being
invoked with a dynamic dispatch, something like the above would let me
immediately start sending as soon as the remote side requested a
connection, for example. It would also let me do something like "accept
a message coming in and put it on the screen, or accept a line from the
keyboard and send it over the socket."

But if Ada can't do this, I'm going to have to come up with a different
way of doing it which will be (I fear) far more painful and obtuse. I'm
expecting I'll have to basically package up all the parameters and build
queues of messages, and essentially reimplement all the entry queueing
stuff myself.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
                   Who is this Dr. Ibid anyway, 
                  and how does he know so much?