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-09 12:31:42 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.cs.ubc.ca!cyclone.bc.net!sjcppf01.usenetserver.com!usenetserver.com!news-west.rr.com!lsnws01.we.mediaone.net!typhoon.san.rr.com!not-for-mail Message-ID: <3BC34F54.BD6B5EDE@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: <3BC31A54.F33F03D1@san.rr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 09 Oct 2001 19:26:27 GMT NNTP-Posting-Host: 66.75.151.160 X-Complaints-To: abuse@rr.com X-Trace: typhoon.san.rr.com 1002655587 66.75.151.160 (Tue, 09 Oct 2001 12:26:27 PDT) NNTP-Posting-Date: Tue, 09 Oct 2001 12:26:27 PDT Xref: archiver1.google.com comp.lang.ada:14078 Date: 2001-10-09T19:26:27+00:00 List-Id: 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?