VNC Server

David M.Siegel dsiegel at mindspring.com
Mon Apr 17 19:24:59 UTC 2000



Lex Spoon wrote:

> It would be much better to display some "waiting" graphics while waiting
> for the data to download, all errors aside.  But now the calling code
> is explicitly aware of the fact that a message send is really just a
> send/receive pair in disguise.  Did we gain enough from disguising it,
> that it is worth this kind of coding?  I dunno.

You're explicitly giving the developer the mechanism to defer receiving
a result as long as possible.

This is far from transparency, but seems to have some value.

> > > As a small detail, it also doesn't let you do "x zap" and get a promise
> > > cascaded on the original....
>
> You actually can send zap immediately.  The distributed object system I
> put together would let you do this, for example.  All you have to
> do is have the remote side remember which promises it has
> fulfilled for a little while.

I'm sorry that I didn't make this explicit in my previous message.
I was careful to state that the application message "zap" couldn't
be sent.  The framework could certainly preposition the message
at the best site for execution, but would have to defer executing
the message "zap" at that site until "x"'s value had been
determined, or determined not to exist.

> In fact, many otherwise expensive operations can be executed very
> quickly by cascading messages like this--the messages end up being
> pipelined over the network connection.  "x a b c d e f" ends up sending
> a, b, c, d, e, and f back to back over the network.  Eventually, the
> remote side will send back all six answers back to back.  With
> synchronization, the #b doesn't get sent until #a's answer comes back,
> and so on.
>
> So the ideal scheme for working with promises, it seems to me, is to
> simply have points where the user can explicitly synchronize the
> value.  Then, a good programmer just inserts the checks at appropriate
> critical points, and otherwise lets the system run at maximum efficieny.

Agreed.  I should have expressed myself a little more carefully.  Rather
than explicitly waiting for "x" to receive a "value" message, wait until
"x"'s value has been determined, which could be noticed by the framework
on the remote side of a connection, permitting results to be pipelined
back to the originator.

> Anyway, to beat my dead horse one more time, you'd still need to know
> which objects are potentially remote.  For example, you can't just swap
> in a RemoteCanvas, until the world's drawing code is explicitly
> modified to deal with potential network failures.

There we're in agreement.  In any case, you'll want relatively coarse grain
remote calls for reasonable performance.  One failing of systems that aim
at transparency is frequent fine grain remote calls leading to low performance.

-dms





More information about the Squeak-dev mailing list