[Openmcl-devel] Unix signal handling

Scott L. Burson Scott at sympoiesis.com
Tue Jul 6 20:21:40 UTC 2010

On Tue, Jul 6, 2010 at 11:52 AM, Gary Byers <gb at clozure.com> wrote:

> On Tue, 6 Jul 2010, Daniel Weinreb wrote:
>  You added  ccl:*quit-interrupt-hook*, which is called
>> on SIGTERM.  Does it have these problems?
> No.
> There's a handler for SIGTERM (and SIGINT and IIRC SIGQUIT)
> in the lisp kernel; it just sets a flag in memory indicating
> which of those signals have been received since the flag was
> last cleared.
> Some lisp code that runs a few times a second checks/clears that flag
> and interrupts some thread.  There are a few hooks that give a little
> bit of control over what thread gets interrupted and (in the case of
> SIGQUIT/SIGTERM) what function gets called.  That's (at most) just a
> matter of interrupting a thread via PROCESS-INTERRUPT, and
> PROCESS-INTERRUPT tries to be very careful about when/how the target
> thread is interrupted.
> A more general mechanism would allow you to do something like:
> (define-signal-handler SIGQUIT
>  ;; This runs on an arbitrary thread at a more-or-less arbitrary
>  ;; time.  The implementation has ensured that it's GC-safe to
>  ;; run lisp code now; beyond that, you have enough rope to hang
>  ;; yourself in lots of ways, and you may not be able to safely
>  ;; do too much more than set a flag here.
>  (arbitrary-code ...))
> but that mechanism doesn't exist and would require some implementation
> support to even offer the GC-safety that the comment describes.
But couldn't this mechanism be implemented in exactly the same way as you
have described doing for SIGTERM?  It would certainly be adequate for my
needs; I don't need microsecond response times (though 250ms would be a bit
on the long side; maybe the poll rate of "a few times a second" needs to be
20/sec or so).

-- Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.clozure.com/pipermail/openmcl-devel/attachments/20100706/8b231faa/attachment.html>

More information about the Openmcl-devel mailing list