[cmucl-imp] gc & blocked signals

[Raymond Toy]

On Wed, Feb 1, 2012 at 12:32 AM, Helmut Eller <heller at 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