From: Barry Margolin
Subject: Re: LISP read-eval-print loop
Date: 
Message-ID: <1991Sep12.005825.18637@Think.COM>
In article <······················@CSD-NewsHost.Stanford.EDU> ···@Neon.Stanford.EDU (Patrick Cheng S Teo) writes:
>I'm working on getting two processes to communicate with each other via a
>socket.  One of them is written in C while the other is written in LISP.
>I need the LISP program to be interpreted, i.e. there should be an image
>of the LISP interpreter (which is forked from the C program).  I would
>like to give the user the ability to use the LISP interpreter while at the
>same time, the C program can preempt the user and send commands to the LISP
>window itself.  I was thinking of using the *eval-hook* but will this
>work if the LISP interpreter blocks on input?  Does anyone have any other
>suggestions?

You are correct that the *EVALHOOK* mechanism won't work while the
interpreter is blocked for input.

Since the user must issue some command to start this mechanism up (using
your original suggestion, he must call the function that sets *EVALHOOK*),
you don't really have to modify the standard read-eval-print loop, you
could have this function invoke a read-eval-print loop of your own.  Your
read-eval-print loop could sit in a loop alternately calling LISTEN on the
stream socket and *STANDARD-INPUT*.  This is kind of gross, though, because
it never blocks.

If you're using sockets from Lisp, then completely portability isn't an
issue.  Some Lisp implementations provide multithreading within the Lisp
process (they often call this multiprocessing, but I'm using a different
term so as not to confuse them with Unix processes).  You could have a
background thread dealing with the socket, while the foreground thread is
in the standard read-eval-print loop.
-- 
Barry Margolin, Thinking Machines Corp.

······@think.com
{uunet,harvard}!think!barmar