[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

handling a keyboard interrupt



    Date: Mon, 23 Apr 90 11:44:02 PDT
    From: kosma%flow@STC.LOCKHEED.COM (Monty Kosma)

       From: jwalker@crl.dec.com
       Date: Fri, 20 Apr 90 17:31:13 EDT

       I think you want to look at the documentation in the section
       called Conditions.  You don't want to handle keyboard
       interrupts; you want to provide your own handler for
       conditions like sys:abort.  It takes some time staring at
       examples to figure out this condition stuff but it is
       cleaner than what I think you are thinking of.

    This is true; however, with lucid 3.0 which I've been using lately, the
    condition stuff does just about everything EXCEPT handle keyboard
    interrupts.  It's too bad they didn't/couldn't hook it into the CL
    condition stuff.  Anyway, I'll do this for the symbolics code.  thanks....

It should be pretty easy to write your own Lucid interrupt handlers that
turn keyboard interrupts into conditions as Symbolics does.  The only
caveat is that the interface from Lucid to Unix signals is undocumented
and internal:

(lucid::setup-interrupt-handler <interrupt-number> <handler>)

<interrupt-number> is a Unix signal number, and <handler> is either
:IGNORE or a function of two arguments, the signal number and a code
(which I assume are the same as the parameters passed to a signal
handler defined by the C function signal()).  Something like this should
work:

(define-condition abort (condition) ()
  ...)

(defun ^C-handler (signal code)
  (declare (ignore signal code))
  (interrupt-process *keyboard-interrupt-process*
		     #'(lambda () (signal 'abort))))

(defconstant SIGINT 2)

(lucid::setup-interrupt-handler SIGINT #'^C-handler)

This makes ^C in Lucid equivalent to C-Abort in Genera.  However, you'll
still have to set up handlers for it.

                                                barmar