asheem@mandrill.CWRU.Edu (Asheem Chandna) (10/06/87)
Hi,
After the recent discussions on "passing procedures as parameters," we
were thinking about some of the issues related to "passing procedures as
parameters over multi-processor target systems," and wondered if someone
on the net could perhaps discuss some of the issues, and enlighten us.
Of course (as discussed earlier on the net), Ada doesn't allow for the
passing of procedures as parameters (or at least not yet)!
Consider the case where an Ada program is written such that it contains
several tasks, each directed to a particular processor (by means of say a
pragma statement), and that these tasks use the rendezvous mechanism for
their communication. We want to pass procedures as parameters between the
tasks.
We are assuming, that only procedure names, not entire procedure calls with
parameters specified, would be the objects passed. One would probably prefer to
avoid passing a copy of an entire procedure over the local area network
for several reasons including the fact that processors may also have different
instruction set architectures. ALGOL-60 has the "call by name" parameter
passing mechanism where whole procedure calls could be passed -- one probably
wouldn't want to apply anything like that in this situation.
Now, any task making a procedure call will want a copy of the procedure in its
local environment. If one such task was passed another procedure, surely a copy
of that procedure should be in its local environment. Now, if a rendezvous from
a task residing outside the local environment passes a procedure through an
accept statement into the local environment, could one know the identity of the
set of possible procedures at compile time (from all the procedures available
of that particular type), and arrange to have copies resident in the local
environment? Is this a feasible solution or are we just thinking crazy?
Or, what are some other methods that could be applied towards tackling this
and related issues?
Thanks in advance for your comments.
Asheem Chandna and William Schultz.
VOICE: 216-368-4087
SNAIL: Center for Automation & Intelligent Systems Research,
Case Western Reserve University, Cleveland, Ohio 44106.
UUCP: asheem@mandrill.uucp OR {cbosgd,decvax,sun}!mandrill!asheem
ARPA: asheem@mandrill.cwru.edu OR asheem%mandrill.cwru.edu@berkeley.edu
CSNET: asheem@mandrill.cwru.edu OR asheem@case.csnethyland@esosun.UUCP (Steve Hyland) (10/07/87)
In article <2268@mandrill.CWRU.Edu> asheem@mandrill.UUCP (Asheem Chandna) writes: >Now, any task making a procedure call will want a copy of the procedure in its >local environment. If one such task was passed another procedure, surely a copy >of that procedure should be in its local environment. Now, if a rendezvous from >a task residing outside the local environment passes a procedure through an >accept statement into the local environment, could one know the identity of the >set of possible procedures at compile time (from all the procedures available >of that particular type), and arrange to have copies resident in the local >environment? Is this a feasible solution or are we just thinking crazy? > >Or, what are some other methods that could be applied towards tackling this >and related issues? > Asheem: I was in on this discussion because I've been banging my head up against the wall trying to design a nice mechanism for associating call_back procedures and event_handlers for my X Toolkit package. Here's what I'm now modeling: I am creating mappings between objects in a domain and objects in a range. Just as I can iterate through the objects in the domain and the objects in the range, I can visit one object in the range. In my mapping package, I supply a generic Visit procedure that allows me this visitation right. The code looks something like this: generic with procedure message ( parameter_list ); procedure Visit ( OBJECT : in range ); the procedure Visit calls this message procedure. But the part I really like is this - message can be a procedure OR an entry, so long as it has the same parameter list. So, for instance, using tasking: task Dummy is entry dummy_message ( parameter_list ); end Dummy; with Dummy; procedure Dummy_Visit is new Visit ( Message => dummy_message ); and when Dummy_Visit is called, it calls Dummy's entry. You could alternatively associate that with a procedure call if you preferred. I like this solution because it allows me to make a widget a more general case with event_handlers and call_backs that can be associated with these objects by the user. I hope this helps. Has anyone else done anything similar ? Steve Hyland SAIC Thanks to Mitchell Garth at Alsys for explaining about matching a formal subprogram with an entry (LRM 12.3.6). P.S. Grady, I got this idea from your new book. Any thoughts ?