[Openmcl-devel] Unix signal handling

[Scott L. Burson]

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: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20100706/8b231faa/attachment.htm>