[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Defpascal question
- To: CAMPER@AppleLink.Apple.COM (Camper, Dan)
- Subject: Re: Defpascal question
- From: email@example.com (Bill St. Clair)
- Date: Thu, 4 Nov 1993 09:20:43 -0600
- Cc: info-mcl
At 1:49 PM 11/4/93 +0000, Camper, Dan wrote:
>Question regarding the use of defpascal:
>Are there any guidelines for what you can/cannot do within a defpascal function
>or within a function directly called from there? I'm thinking of potential
>problems with moving memory, interrupting the current MCL process, etc.. I
>don't want to go around rearranging vast amounts of memory without the
>"correct" process knowing about it.
>I know that some callbacks can occur during interrupt time, so that leads to
>another question: What is the proper way to write MCL code to handle those
>callbacks? Just queue up a handler form (via eval-enqueue) as fast as
>possible? Should I even attempt to handle those types of callbacks in Lisp?
DEFPASCAL code must be called synchronously, e.g. MCL calls a foreign
function or a trap and passes a DEFPASCAL function which is called
during the dynamic extent of the foreign function or trap.
This means you cannot use them for interrupt routines or completion
routines. Since they happen synchronously, there are no guidelines
for moving memory. It is in general a bad idea to THROW out of a
callback, though it often works.
If you need to handle a completion routine or interrupt, you CANNOT
use DEFPASCAL. You'll need to write C or Pascal and import it
with the fireign function interface, or write LAP and move it into
the Mac heap, or use the package that I uploaded a few weeks ago
that queues up completion routine args for processing as soon as
MCL can get to it. This last method will work for completion routines
that are not time critical and that don't need to return a value.
The code is available for anonymous FTP from cambrige.apple.com
in the file "/pub/mcl2/contrib/define-interrupt-handler.lisp".