EVAL service

[gadbois@cs.utexas.edu]

    Date: Thu, 24 Oct 91 18:01:58 GMT
    From: smith@icat.larc.nasa.gov (Steven L. Smith)

    I'm trying to develop a fast communications link between two
    Symbolics machines. Information sent between hosts are in the form
    of ASCII strings.  The following code, which would be loaded on
    both hosts, is our current implementation:

    [code elided]

    The communication time required to send the form to host B,
    evaluate it, and return the result back to A is the most time
    consuming. One possible way to speed things up is to keep the
    stream open during the session and close it upon exiting the
    program (although not to sure how to do this).

    Anyway, if you have any ideas or know of a faster way to implement
    this, please let me know. Thanks in advance.


Note that Genera comes with a built-in Chaos-based eval server.  It is
pretty much what you have done.

If you are always communicating between lispms, you could drop the
:ASCII-TRANSLATION stream argument and so avoid doing character
translation.  This is probably pretty trivial, though.

Connection initiation involves a fair amount of overhead, so you might
want to keep the connection open -- have the server basically go
through a READ-EVAL-PRINT loop and only quit when it receives some
special token.  The user side could just return a closure that
encapsulates the network stream.  Try meta-pointing on :EVAL to see
how the Genera  server works.

Better yet, since there is an incredible amount of overhead associated
with READing and PRINTing, and if you know ahead of time what kinds of
things you will be evaluating, you might define a specialized protocol
that knows about them and communicates them concisely.  Along this
vein, if you don't need the generality of EVAL, the Network RPC
substrate makes it pretty easy to cobble together specialized compute
services.

If you need to use EVAL, note that there are a few of other things
to take care of if you want a robust protocol:

1. If the form being evalled on the server causes an error, the server
should catch it and send back some indication of what happened.

2. You have to be careful about printing unreadble objects like #<FOO
1234567> .  Make sure *PRINT-READBLY* is T and stage your form
and results into a buffer before sending them out over the stream
(Note that I may have some of the names wrong here -- I'm stuck using
a UNIX box today):

	(princ
	   (with-output-to-string (stream)
	     (condition-case (c)
		 (let ((*print-readably* t))
		    (print form stream))
		(print-not-readable
		  ... handle it ... )))
	    stream)

3. If the forms may do input or output through *TERMINAL-IO*, you get
annoying notifications from the server process.  There are many ways
to deal with this.  The simplest is probably to bind *TERMINAL-IO* to
SYS:NULL-STREAM, which causes output to be dropped on the floor and
input to cause an error that can be dealt with by the general error
handler (see point 1.).

--David Gadbois