Re: Dynamic dispatch again

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

tmoran@acm.org wrote:
> 
> >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


>   I'm not sure I understand what you are trying to do.  It sounds like
> you want a bunch of low level tasks running various message channels.

No. It's the high-level tasks running the message channels. 

Think of it this way - pretend I'm implementing a TCP/IP stack in Ada.
As each IP packet comes in, I want to invoke something to do an accept,
deliver data, or indicate an end-of-file. However, each port is going to
indicate a different process, and each of those processes is going to
block (or maybe not!) when it calls read, when it calls open, when it
calls close, etc. Not all invocations of "read" will be from the same
point in a process. Some entries getting invoked might abort other
processing in progress, etc. The interactions between the library I'm
writing (which is low in the protocol stack) and the applications on top
of it (the "profiles" at the top of the protocol stack) are rather more
complex than TCP, but you get the idea. (For full details, RFC3080, or
www.beepcore.org.)

BEEP is similar in what it does to TCP
multiplexing/windowing/buffering/handshaking/etc, except at the
application layer. It's kind of a (ISO-speak) session layer for TCP/IP.

I don't want the TCP-like buffers being managed by the user processes
(i.e., the tasks) because it just isn't elegant. Sure, I can package up
everything and stuff it in queues, and then have the readers dequeue the
message, perhaps blocking until one arrives or not, then dispatching
internally. But it isn't elegant. It's how you have to do it in a lesser
language that doesn't even have proper rendezvous built in.

> Ignoring implementation,
> can you write down the specifications for the abstraction you want
> your users to see.

Sure. It's about 40 pages. :-)  That's a lot of work for something that
can't be implemented, tho. What I'm trying to work out is whether it's
worth writing it all out to start with. Kind of silly to spend a week
writing up a spec I *know* can't be implemented.

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