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-10 11:17:04 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cyclone2.usenetserver.com!usenetserver.com!news-east.rr.com!cyclone.kc.rr.com!news.kc.rr.com!news-west.rr.com!lsnws01.we.mediaone.net!typhoon.san.rr.com!not-for-mail Message-ID: <3BC4909E.A81E2507@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: <3BC34F54.BD6B5EDE@san.rr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 10 Oct 2001 18:17:18 GMT NNTP-Posting-Host: 66.75.151.160 X-Complaints-To: abuse@rr.com X-Trace: typhoon.san.rr.com 1002737838 66.75.151.160 (Wed, 10 Oct 2001 11:17:18 PDT) NNTP-Posting-Date: Wed, 10 Oct 2001 11:17:18 PDT Xref: archiver1.google.com comp.lang.ada:14194 Date: 2001-10-10T18:17:18+00:00 List-Id: tmoran@acm.org wrote: > > > > can you write down the specifications for the abstraction you want > > Sure. It's about 40 pages. :-) That's a lot of work for something that > A prospectus would suffice. Well, here's a *very* simplified version of the tasking interface. It's hard to work these things out completely when you know there are fundamental stumbling blocks. :-) My current approach right now involves either defining the "profile instance" as a tagged type with a pair of queues (for commands coming up and commands going down) and let you put your own task in that, with the controller also having a queue and distributing things to the appropriate instances, - or - having profile instances being tagged types with procedures instead of entries and letting each profile instance implement the procedures as calls to entries on a task it starts up when instantiated. Both techniques have both a lot of advantages and a lot of disadvantages. I'm not yet sure which is better, but I'm starting with the former and seeing how it starts to look. +=+=+=+ task type profile_instance_task is -- The task is started, then this is called -- to find out if it's willing to run. entry start( Server : in Server_Name; Which_URI : in URI; Result : out Diagnostic); -- Return code 200 for success. -- This is called to deliver a frame to the instance. entry frame_up(f : in Frame); -- This is called to request or force the instance -- to close down. entry close( Who : in (Local, Remote, Socket); Why : in (Close, Reset); Result : out Diagnostic); end profile_instance_task; task type controller_task is -- This is called to configure the controller. entry setup( Reg : in Registry; Sock : in Socket; Config : in Configuration); -- THE ABOVE IS PART OF THE PROBLEM. The registry has to (basically) -- map strings to task bodies, where each task body has the same -- entries as profile_instance_task, but where the actual code -- executed is different. The problem is that the "accept" statements -- must actually appear inside the task body, and there's only -- one task body per task type, and a requeue references an -- object of a specific task type. If I want to accept a call -- to frame_up, but call frame_down if I don't get a frame_up -- within 5 seconds, I'm pretty screwed with a task-oriented -- interface design. I also cannot do something like -- select close(...) ... then abort loop frame_down(...); end loop; -- This is called by the instance to queue a frame. entry frame_down(f : in Frame); -- This is called by the frame_out_pump to get a frame -- to be sent over the socket. entry frame_out(f : out Frame); -- This is called by the frame_in_pump to deliver a frame -- from the socket to the controller. entry frame_in(f : in Frame); -- This requests the controller start a new profile instance. entry start( PL : in Profile_List; Diag : out Diagnostic; Chan : out Integer); -- This requests the controller to close a channel or an entire session. entry close( Chan : in Integer; Diag : out Diagnostic); end controller_task; -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. Who is this Dr. Ibid anyway, and how does he know so much?