I have been trying to hook up a C++ screen interface system to
a large lisp project written in Sun Common Lisp.
I tried using InterProcess Communication:
I wrote two small C programs that used the message handling functions i
msgget and msgrcv. One would
put the message out to be read, the other would get the message.
I tested them at the operating system level (without lisp) and they
worked. I could start the get program in one window & it would
wait until I did the put in another window & the data would exchange.
The next step was to call the get function from lisp.
I used the Sun Common Lisp foreign function interface to allow the
lisp code to call the get function.
I could get the foreign function interface to work as long as I was
not doing InterProcess Communication!
I got the help of someone who knows the operating system pretty well.
His conclusion was that Sun Common Lisp is relying upon and manipulating
the very things that we were using to send messages.
It seems that Lisp was mucking around with system signals.
I looked into callable functions from lisp.
I tried a simple callable C function and it tested fine.
However, once I changed the C function to take input from the
keyboard and ran it, I got:
>>Trap: Interrupt: bus error
I'm about ready to do the communication through a common file!
Any ideas?
thanks in advance,
-mark (·····@udel.edu)
From: Barry Margolin
Subject: Re: Foreign input interface with Sun common lisp program
Date:
Message-ID: <kvomj1INNnga@early-bird.think.com>
In article <······················@udel.edu> ·····@mars.cis.udel.edu (Mark Jones) writes:
> His conclusion was that Sun Common Lisp is relying upon and manipulating
> the very things that we were using to send messages.
> It seems that Lisp was mucking around with system signals.
Yes, Lucid Lisp sets up many of its own signal handlers. Some it uses for
its own purposes (e.g. it has a handler for SIGFPE so that it can report
floating point overflows and such, and handles SIGALRM for its multiple
processes facility), but I think it just initializes most to a known state.
However, if your C function is using signal(3) to set up its own handler
for a signal, I don't think Lisp will override it. What signal are you
using?
You can set up your own Lisp interrupt handlers with
SYSTEM:SETUP-INTERRUPT-HANDLER. The first argument is the interrupt
number, and the second argument is either a handler function (or a symbol
naming the function) or one of the symbols :DEFAULT or :IGNORE. There's
also SYSTEM:GET-LISP-INTERRUPT-HANDLER, which returns the current setting.
This just extracts the value that Lisp remembers setting; if the C function
has since overridden Lisp, it won't show up from this function (hence the
"LISP" in the name).
>I looked into callable functions from lisp.
> I tried a simple callable C function and it tested fine.
> However, once I changed the C function to take input from the
> keyboard and ran it, I got:
> >>Trap: Interrupt: bus error
I have no idea what's going on here. Part of the problem is that I can't
tell when you're talking about the C function or the Lisp function. Is a
"callable C function" a C function, or a Lisp function that's callable from
C (as defined with DEF-FOREIGN-CALLABLE)? And which function did you
change to take input from the keyboard, the Lisp function or the C
function? If the C function, are you using stdio? That might not work
well, since Lisp is doing some of its own buffering.
--
Barry Margolin
System Manager, Thinking Machines Corp.
······@think.com {uunet,harvard}!think!barmar