[Openmcl-devel] Unix signal handling
dlw at itasoftware.com
Tue Jul 6 12:53:20 CDT 2010
You added ccl:*quit-interrupt-hook*, which is called
on SIGTERM. Does it have these problems? It might
not be that important for us, since what we're going
to do is a shutdown anyway, but, if it's going to be
flaky, I'd at least like to know what we're up against.
Gary Byers wrote:
> On Mon, 5 Jul 2010, Scott L. Burson wrote:
>> I am porting a large, old application from Allegro to Clozure. The
>> app runs
>> under Emacs -- it has its own code, on both the Emacs and Lisp sides,
>> doing this -- and Emacs sometimes gets the Lisp process's attention by
>> sending it a Unix signal (normally SIGUSR1 or SIGUSR2, but this is
>> Allegro provides a relatively straightforward way to set up a Lisp
>> to be called when a signal is received, but I don't see anything like
>> in CCL. Have I just overlooked it? If not, how hard would it be to
> There isn't any general way of defining signal handlers in CCL. The
> comes up every few months on this list, and the response is usually
> we should offer that. Someday." It's almost certainly doable, but
> there are
> threads/GC issues that make the implementation complicated.
> Additionally, the implementation of things like PROCESS-INTERRUPT and the
> mechanism that the GC uses to suspend/resume other threads involves
> signals between threads; on some platforms (Darwin), the
> implementation uses
> SIGUSR1 and SIGUSR2 and possibly something else that the OS never
> raises, and
> it's not clear that there are any leftover unused signal numbers ...
> It might be tempting to just do:
> (defcallback my-signal-handler (:int signo :void)
> (#_signal #$some-signal my-signal-handler)
> and that'd work some of the time. It'd fail (subtly or spectacularly)
> if the
> GC ran in some other thread and that signal handler interrupted some
> lisp code.
> (The GC would likely not be able to see the lisp object references
> that that
> interrupted code was making, and things would go downhill from
> there.) There
> are some other issues there, so any viable mechanism would have to
> deal with
> those issues around a call to your code.
>> Alternatives exist, of course -- I could set up another stream with a
>> thread reading from it, and just send a character on the stream. Sounds
>> like a bit of work, though I haven't looked into it; not sure if
>> Emacs will
>> cooperate. Anyway I wanted to explore the signal handling approach
>> since that is how it works with Allegro.
>> Any advice?
>> -- Scott
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openmcl-devel