Re: gc & blocked signals

* 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.

>
>>  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.

Helmut

_______________________________________________
cmucl-imp mailing list
[email protected]
http://lists.zs64.net/mailman/listinfo/cmucl-imp