Re: Dynamic dispatch again

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

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?