Re2: Defpascal question

[CAMPER@AppleLink.Apple.COM (Camper, Dan)]

>>Question regarding the use of defpascal:
>>
>>Are there any guidelines for what you can/cannot do within a defpascal funct
ion
>>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".
 
Thanks for the clarification.  Unfortunately, it brings up another question.
The reason I posted my original note was due to problem I discovered with Apple
Events:  I had written an AE handler and was testing it with a small function
in MCL (MCL was sending the event to itself, in other words).  My handler was
dying, apparently because the reply description was being trashed, but the
whole thing worked wonderfully if I exported the test function to another Mac
on the network.
 
I had made some modifications to the highlevel-event module so as to handle
suspended Apple Events and I thought that's where my problem was.
Unfortunately, I could duplicate the problem with a "virgin" MCL 2.0.1.
 
At any rate, the #'defer-appleevent (defpascal) function is what the OS calls
when an event comes in.  That function checks to see if MCL originated it and,
if it did, *immediately* calls the appropriate Lisp handler.  My handler was
moving a lot memory around, accessing a 10MB disk file.  This apparently caused
the -1704 error.
 
So:  Does this point to a problem within MCL or am I making this up on my own
(a likely possibility, indeed)?
 
Dan