VNC Server

Lex Spoon lex at cc.gatech.edu
Mon Apr 17 07:47:16 UTC 2000


"David M.Siegel" <dsiegel at mindspring.com> wrote:
> > Second, method invocation is a bit of a misfit for networks, which are
> > based on disconnected sends and receives.  It's bad to do a send and
> > then have to wait for a reply, so direct RMI is probably not the best
> > strategy.  RMI with "promises" might be workable, but it's tricky.  What
> > happens if the return value is actually an error?  Oops, you shouldn't
> > have kept executing!
> 
> No.  The design should only have to consider the error at the point the
> promise's value is first requested.

Okay, this might be workable, assuming the programmer is prepared for
it.  But it's certainly not normal--If I retrieve an HTML page and get a
promise back, I'm liable to start creating a browser window to display
it in.  If there turns out to be an error, then I've made a mistake by
even *starting* to open the window.

A similar problem has plagued ML tools that want to speculatively
execute code portions in parallel.  If any of the branches wants to do
something like I/O that can't be backed out of, then you need to check
if all the semantically preceding expressions finished successfully
before you do it.  (And of course if an error does happen, then you have
to be careful and back out of all the speculative branches).

But again, if programmers know to deal with this situation, it could be
workable.  It's just different than normal local semantics-- it allows
you to do "x := foo bar" and not even be sure when it finishes whether x
is an actual value....

As a small detail, it also doesn't let you do "x zap" and get a promise
cascaded on the original....


-Lex





More information about the Squeak-dev mailing list