Re: Dynamic dispatch again

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

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?