<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Actually, on thinking about this some more, a message queue isn't necessary because signals are already segregated by the OS.  So something like this should work:<div><br></div><div><div>(defmacro set-signal-handler (signo &body body)</div><div>  (let ((sem (make-semaphore))</div><div>        (handler (gensym "HANDLER")))</div><div>    `(progn</div><div>       (defcallback ,handler (:int signo :void)</div><div>         (declare (ignore signo))</div><div>         (signal-semaphore ',sem))</div><div>       (#_signal ,signo ,handler)</div><div>       (process-run-function ,(format nil "SIGNAL ~A HANDLER" signo)</div><div>                             (lambda ()</div><div>                               (loop</div><div>                                 (wait-on-semaphore ',sem)</div><div>                                 ,@body))))))</div></div><div><br></div><div>I tried it and it actually does seem to work.  To really make this bulletproof you'd want to tweak it so that calling set-signal-handler multiple times on the same signals didn't leave garbage processes lying around.</div><div><br></div><div>rg</div><div><br><div><div>On Jul 6, 2010, at 3:57 PM, Ron Garret wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Seems to me the Right Way to do this is not to poll but to set up a message queue.  The actual signal handlers would push their signal number onto the queue, and then there would be a signal servicing thread popping things off the queue and calling the appropriate (user-settable) handler function, which would now be running in a regular Lisp callback context.  Seems like this ought to be doable at the user level through the FFI.<div><br></div><div>rg</div><div><br></div><div><div><div>On Jul 6, 2010, at 1:21 PM, Scott L. Burson wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Tue, Jul 6, 2010 at 11:52 AM, Gary Byers <span dir="ltr"><<a href="mailto:gb@clozure.com">gb@clozure.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
<br>
On Tue, 6 Jul 2010, Daniel Weinreb wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
You added  ccl:*quit-interrupt-hook*, which is called<br>
on SIGTERM.  Does it have these problems?<br>
</blockquote>
<br></div>
No.<br>
<br>
There's a handler for SIGTERM (and SIGINT and IIRC SIGQUIT)<br>
in the lisp kernel; it just sets a flag in memory indicating<br>
which of those signals have been received since the flag was<br>
last cleared.<br>
<br>
Some lisp code that runs a few times a second checks/clears that flag<br>
and interrupts some thread.  There are a few hooks that give a little<br>
bit of control over what thread gets interrupted and (in the case of<br>
SIGQUIT/SIGTERM) what function gets called.  That's (at most) just a<br>
matter of interrupting a thread via PROCESS-INTERRUPT, and<br>
PROCESS-INTERRUPT tries to be very careful about when/how the target<br>
thread is interrupted.<br>
<br>
A more general mechanism would allow you to do something like:<br>
<br>
(define-signal-handler SIGQUIT<br>
  ;; This runs on an arbitrary thread at a more-or-less arbitrary<br>
  ;; time.  The implementation has ensured that it's GC-safe to<br>
  ;; run lisp code now; beyond that, you have enough rope to hang<br>
  ;; yourself in lots of ways, and you may not be able to safely<br>
  ;; do too much more than set a flag here.<br>
  (arbitrary-code ...))<br>
<br>
but that mechanism doesn't exist and would require some implementation<br>
support to even offer the GC-safety that the comment describes.<br><br></blockquote><div> </div></div>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).<br>
<br>-- Scott<br><br>
_______________________________________________<br>Openmcl-devel mailing list<br><a href="mailto:Openmcl-devel@clozure.com">Openmcl-devel@clozure.com</a><br><a href="http://clozure.com/mailman/listinfo/openmcl-devel">http://clozure.com/mailman/listinfo/openmcl-devel</a><br></blockquote></div><br></div></div>_______________________________________________<br>Openmcl-devel mailing list<br><a href="mailto:Openmcl-devel@clozure.com">Openmcl-devel@clozure.com</a><br>http://clozure.com/mailman/listinfo/openmcl-devel<br></blockquote></div><br></div></body></html>