user-written interrupt handlers

["Nicholas S Castellano" <entropy@terminator.rs.itd.umich.edu>]

>> 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.
>
> also such a call would have to return quickly if you want to use it
>from a modem interrupt, otherwise you'd get receiver overruns again...

It may help if there were a way to do something like a Pkill() without
the call to check_sigs() at the bottom.  Really all you want to do in
the interrupt handler is mark the signal as pending, and let the
handler be invoked during the next context switch to the process in
question.  That way there is no need for the handler to run at any
particular speed, as the worst that could happen is the signal may
become pending again during the execution of the handler (but it
should be blocked at that point anyway).  I don't think signals are
currently checked during a context switch, so that may need to change
for this to work.

Cheers,
entropy

--
entropy -- it's not just a good idea, it's the second law.
Personal mail:      entropy@gnu.ai.mit.edu
MiNT library mail:  entropy@terminator.rs.itd.umich.edu
"what do you have against octal?" -jrb