The Lisp application we are going to implement will
function as a network black box - accepting requests
to parse a message and then returning a status code.
This means that an efficient foreign function interface
is very important, for both call outs and call backs.
Anyone have any feelings on this wrt Allegro and Lucid?
Thanks
--
Greg Parkinson Phone: 212-657-7814 Fax: 212-825-8607
Citibank,111 Wall Street E-Mail: ···@fig.citib.com
New York, New York 10043
The opinions expressed are my own and not those of the big 'ol bank.
In article <··········@fig.citib.com> ···@fig.citib.com (Greg Parkinson) writes:
From: ···@fig.citib.com (Greg Parkinson)
Organization: Citibank IBISM
Date: Thu, 28 Jan 1993 15:43:12 GMT
The Lisp application we are going to implement will
function as a network black box - accepting requests
to parse a message and then returning a status code.
This means that an efficient foreign function interface
is very important, for both call outs and call backs.
Anyone have any feelings on this wrt Allegro and Lucid?
Hi,
I just wanted to tell you that I've just done something very similar in
Lucid - ako EVAL-SERVER using the standard UNIX system calls.
Fortunately, there is no need to do any C programming since you can just
specify the function prototype specs (using LCL:DEF-FOREIGN-FUNCTION and
LCL:DEF-FOREIGN-STRUCT) and link in the Unix library functions you need,
typically socket(2), bind(2), listen(2), accept(2), connect(2), aso.
Speed is no problem (for this app, anyway) and the fact that I utilise
the built-in Lisp READER instead of introducing my own application
specific message parsing scheme, makes it simple and general.
I haven't worked with Allegro before, so I cannot tell whether you can
do the same things there.
The only thing to look out for, is the nasty interaction between Unix
system calls and the Lucid scheduler - i.e. if you're doing a
multi-tasking application, you must make sure the different threads
don't mix up their Unix system calls.
The general idea behind my approach is reflected in a public domain (GNU
GPL) package called rpc-hm-1.0 available on e.g.
archive.cis.ohio-state.edu in /pub/gnu/emacs/elisp-archive/packages/,
and on ugle.unit.no:/pub/gnu/emacs-lisp/rpc-hm-1.0.tar.Z. This package
implements a GNU Emacs communications interface with a remote Common
Lisp server residing on a Lispm (TI Explorer or Symbolics).
Cheers,
Eyvind.
--
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Eyvind Ness Internet: ···········@HRP.No
Research Scientist Voicenet: +47 9 183100 ext. 275
CRS Division Faxnet: +47 9 187109
OECD HRP Papernet: PO Box 173, N-1751 Halden, Norway
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~