Has anyone written an application in one of those yucky languages
like C or C++ that communicated to a separate lisp process using pipes
or sockets? Care to share your experiences? How did you handle lisp
errors? How about the flushing of the pipe so that you can tell when
lisp is ready to proceed? Anything else I should consider?
Thanks,
Mike McDonald
·······@engr.sgi.com
From: ·······@titian.engr.sgi.com (Mike McDonald)
Date: 19 Apr 1996 18:02:50 GMT
Has anyone written an application in one of those yucky languages
like C or C++ that communicated to a separate lisp process using pipes
or sockets? Care to share your experiences? How did you handle lisp
errors? How about the flushing of the pipe so that you can tell when
lisp is ready to proceed? Anything else I should consider?
ACL/Win has DDE available for inter-process communication. For example,
there is an interface (Editi) between Win-Emacs and ACL that uses DDE.
There is a free demo version of ACL/Win available, see
http://www.franz.com. I'm not sure whether the demo version includes
DDE support or not; ditto for Editi. There's also a free demo version
of Win-Emacs, see http://www.pearlsoft.com.
On Apr 19, 1996 18:02:50 in article <Running lisp as a slave process??>,
········@titian.engr.sgi.com (Mike McDonald)' wrote:
>
>Has anyone written an application in one of those yucky languages
>like C or C++ that communicated to a separate lisp process using pipes
>or sockets? Care to share your experiences? How did you handle lisp
>errors? How about the flushing of the pipe so that you can tell when
>lisp is ready to proceed? Anything else I should consider?
>
I have not experimented with direct socket interface directly from
Lisp, but I have done several projects in client-server style. My
method has been to always make the Lisp module the server and the
GUI module the client.
To make the socket connections, I wrote a small shared object
library to load and link into the Lisp image and used Allegro's
foreign function interface to communicate with this lib. Since
this has always been used with GUI front ends, the extra
inefficiency has bee completely unnoticeable.
The SO library, written in C, provides the following interfaces
callable from Lisp:
AcceptConnection()
CloseConnection()
GetMessage()
SendMessage()
ReadData()
WriteData()
After the Lisp process starts and completes whatever initiali-
zations it needs to do, it calls goes into a message loop:
(when (init-server)
(loop as clientfd = (AcceptClient)
do
(loop as msgid = (GetMessage clientfd)
until (= msgid *disconnect*)
finally (close-connection clientfd)
do
(cond ((= msgid *send-some-stuff*)
(let ((string (function-to-package-data-string))
(write-data clientfd msgid string (1+ (length string)))))
((= msgid *receive-some-stuff*)
;; actually, GetMessage returns a C struct
;; that also contains the size of the
;; associated data string.
(decode-data (read-data clientfd nbytes)))
.... and so on
As far as handling Lisp errors, I use conditions to somehow
recover -- when writing a server, it MUST be able to recover
and continue under all but the most unusual situations -- and
resume the GetMessage loop. No problems so far.
Now that we finally have direct socket handling within Lisp,
I plan to use it to eliminate the shared object library.
But the plan is to use the same message-loop mechanism as
it has proved to be quite robust and reliable for me.
BTW, the front ends were written in C/C++ as well as
Basic (MSVB).
If you have more questions, feel free to e-mail. I don't
feel comfortable in sharing the code as it belongs to my
client, but there should be no problem in sharing the
design and implementation techniques.
--
Pete Grant
Kalevi, Inc.
Software Engineering & development