budd@mist.cs.orst.edu (Tim Budd) (02/02/89)
[ Is there a newsgroup specifically devoted to discussion of linda? ]
{
not that I know of....steve
}
In implementing Linda, one of the more difficult problems would seem to be
the correct handling of eval(). I'm particularly curious as to how eval()
is done in systems such as Leichter's VAX/VMS ethernet implementation,
where it is not possible to simply fork off a child of the process on one
machine and expect that it will take up residence on a different machine.
Do they just punt and not implement eval?
I've never been exactly certain of the exact semantics of eval, either.
Here are two questions:
1. Can an eval'ing process in() it's own tuple? does this have any effect
on the executing computation? That is, can I do something like
eval("foo", bar());
where bar is
bar() {
... do some stuff ....
in("foo", x);
... do some more stuff ...
}
will all the stuff be performed?
2. When using typed fields, is it the case (as one would expect) that
the type of a running process produced by an eval is different from the
type of the result produced when that process completes? That is, if
I do something like
eval("foo", bar());
in("foo", x:integer);
where bar is
int bar() {
.. do some stuff ..
return 17;
}
the in() should hang until bar is finished, since prior to that point
the type of the second argument in the typle is a process.
Is my understanding correct?
--tim budd (still waiting to gain access to an actual linda system)
budd@cs.orst.edulbo@ztivax.siemens.com (Dr Lothar Borrmann) (02/06/89)
In article <4282@hubcap.UUCP> budd@mist.cs.orst.edu (Tim Budd) writes: >[ Is there a newsgroup specifically devoted to discussion of linda? ] There has not been too much discussion about Linda in *this* group during the last months. It seems that there is nobody interested (?). >In implementing Linda, one of the more difficult problems would seem to be >the correct handling of eval(). I'm particularly curious as to how eval() >is done in systems such as Leichter's VAX/VMS ethernet implementation, >where it is not possible to simply fork off a child of the process on one >machine and expect that it will take up residence on a different machine. >Do they just punt and not implement eval? According to Sudhir Ahuja, Nicholas Carriero and David Gelernter in *Linda and Friends* (Computer, August 1986) this call is not considered as primitive but can be implemented on top of *out*. When we started *our* Linda work (on top of Modula-2) we heard from Yale that eval implementation had been postponed in *their* Linda systems. However that was about 18 months ago. In our system we distribute work just by OUTing application dependant 'task descriptions'. You may regard such a tuple an 'active' one. The task specification can contain ordinary data as well as the key for a procedure to be called. Even procedure parameters could be included, in case this procedure does not access global data. >I've never been exactly certain of the exact semantics of eval, either. >Here are two questions: > >1. Can an eval'ing process in() it's own tuple? does this have any effect >on the executing computation? That is, can I do something like > > ( ... example deleted) This looks strange. > >2. When using typed fields, is it the case (as one would expect) that >the type of a running process produced by an eval is different from the >type of the result produced when that process completes? That is, if > (...) >the in() should hang until bar is finished, since prior to that point >the type of the second argument in the typle is a process. >Is my understanding correct? > We would think so too. However it seems that David Gelernter should be asked to point out the definite semantics of eval as well as the state of work to implement it. A followup from Yale would be appreciated, I think. _____________________________________________________________________________ Lothar Borrmann Email: Siemens AG UUCP lbo@ztivax.uucp Corporate Research and Technology or ...{uunet}!unido!ztivax!lbo ZFE F2 SYS 3 Otto-Hahn-Ring 6 Internet lbo@ztivax.siemens.com D-8000 Muenchen 83 or lbo%ztivax.uucp@uunet.uu.net West Germany _____________________________________________________________________________
narem-james@YALE.ARPA (James E. Narem Jr.) (02/07/89)
(This is really-from: Nicholas Carriero) In article <4282@hubcap.UUCP> budd@mist.cs.orst.edu (Tim Budd) writes: >[ Is there a newsgroup specifically devoted to discussion of linda? ] Not yet, although there is growing interested in some sort of mailing list. >In implementing Linda, one of the more difficult problems would seem to be >the correct handling of eval(). I'm particularly curious as to how eval() >is done in systems such as Leichter's VAX/VMS ethernet implementation, >where it is not possible to simply fork off a child of the process on one >machine and expect that it will take up residence on a different machine. >Do they just punt and not implement eval? Jerry will more than likely respond with details specific to the VAX/VMS system. Let me sketch some general approaches we've taken to deal with eval. I'll focus on the simple mechanics of getting a new process going, and shy away from the apocalyptic horsemen of binding, pointers and enforcement. Clearly if the target machine is a multiprocessor, like an Encore or Sequent, where a fork gets you a new process running on its own processor, then an eval can be just a simple wrapper around a fork. If the target machine is something like an Intel cube, where you don't have a fork, but you do have a well defined concept of a dedicated pool of processors, we use the following: 1) A compiler transform of eval("foo", foo(x, y, z) to out("sys eval", foo') out("foo' args", x, y, z) 2) A machine generated wrapper function foo'() { in("foo' args", ?a0, ?a1, ?a2); out("foo", foo(a0, a1, a2)); } 3) Arrange for every linda executable to have this startoff eval_server() { if (node_id == MAGIC_ID) { out("sys eval", main'); out("main' args", ...); } while(1) { in("sys eval", ?fp); fp(); } } 4) Load and run the exectuable on every processor in your pool. The node with the magic id will start the ball rolling. For a Unix-LAN system we're developing, we're experimenting with a variation of the above. The eval_server is a daemon and instead of a function pointer, we'll use the path of an executable that will use an invocation argument to select which of the eval'ed function wrappers to execute. The eval_server does a fork/exec of the path with the appropriate argument. >I've never been exactly certain of the exact semantics of eval, either. >Here are two questions: > >1. Can an eval'ing process in() it's own tuple? does this have any effect >on the executing computation? That is, can I do something like > >eval("foo", bar()); > >where bar is > >bar() { > ... do some stuff .... > in("foo", x); > ... do some more stuff ... > } > >will all the stuff be performed? > >2. When using typed fields, is it the case (as one would expect) that >the type of a running process produced by an eval is different from the >type of the result produced when that process completes? That is, if >I do something like > eval("foo", bar()); > in("foo", x:integer); >where bar is > >int bar() { > .. do some stuff .. > return 17; > } > >the in() should hang until bar is finished, since prior to that point >the type of the second argument in the typle is a process. >Is my understanding correct? > >--tim budd (still waiting to gain access to an actual linda system) >budd@cs.orst.edu Basically 2. answers 1.---the 'in' in 1. will block because the only types available (right now at any rate) will match values, not computations. As part of the design of Linda III (basically current Linda with support for multiple tuple spaces) we are considering adding the type adjective "live", which would allow you to express the "paradox" of 1. Figuring out what 1. should do is one of the reasons why designing Linda III has taken so long. For more info: VAX/VMS leichter@cs.yale.edu Unix-LAN arango@cs.yale.edu berndt@cs.yale.edu Cubes bjornson@cs.yale.edu Shared Memory carriero@cs.yale.edu Deep Thoughts gelernter@cs.yale.edu Any of the above for availability of systems. --- Nicholas Carriero