On Wed, Feb 1, 2012 at 12:32 AM, Helmut Eller <heller@common-lisp.net>wrote:
* Raymond Toy [2012-02-01 03:27] writes:
Yeah, that looks like a bug. I think the problem is not with gc, but with the signal handler(s). I was planning on doing some work on the signal handlers to make them simpler, based on what Carl did for Windows. This should make them simpler and safer. Don't know if it will take care of this problem or not.
The problem doesn't occur with an empty loop. Therefore I think it has something to do with GC.
Ok. Can you write up a ticket for this?
29 SIGIO
SLIME uses SIGIO on a socket and if that stays blocked then SLIME can't interrupt the Lisp process. Also note that C-z in the terminal doesn't
Does SIGIO actually work for you? I stopped using it long ago because it caused strange errors to occur (on darwin). I think it's because SIGIO causes interrupts at bad places because cmucl isn't really interrupt-safe.
Works good enough for me (on Linux). The GC should of course be interrupt-safe. The stream code is not reentrant so it is problematic to use streams in signal handlers. SLIME tries to be careful when reading/writing to it's own stream and tries to delay interrupts to safe-points. SLIME can't fix other streams or non-reentrant code, but the situation there is IMO the same as if the debugger is invoked with SIGINT.
I will try sigio with slime again. That will certainly help motivate me to make it work better. (Or frustrate me to switch back to fd-handler. :-( ) Carl has suggested modifying the compiler so that we only take (most) signals at safe points. This will certainly help many situations so we can concentrate on the truly async signals like sigint. Such safe points will have some implications on speed, though. That's for another day (or year). Ray