Re: user-written interrupt handlers

[Howard Chu <hyc@hanauma.jpl.nasa.gov>]

  Signal handlers aren't good replacements for interrupts; they take too
  much time to be serviced -- maybe a tenth of a second, versus a few
  microseconds for an interrupt handler. It would be unusable, for
  instance, for the serial interrupts, while it would be quite appropriate
  for "Monochrome Detect", say.

Well, since my only purpose here was to drive my interrupt-driven sound
routines on the Falcon, that was just fine anyway. (Using the monochrome
detect interrupt, fancy that.)
  
  On the other hand, it should be _possible_ for an interrupt handler to
  raise a signal; for instance, in the case of a SLIP handler, we'd like
  to receive a signal (or whatever) when a datagram has been completely
  received, not at every received character...
  
  But I don't know if it is safe to call Pkill (via the kernel) in an
  interrupt handler.

That's exactly what my psigintr code does, it allows an interrupt handler to
raise a signal. It does it by calling post_sig directly, which is the actual
kernel routine that Pkill calls to raise the signal in the target process. It
also avoids calling check_sigs, so no problems there either. I would guess this
would also make an ideal approach for a SLIP or PPP handler...