Re: [Chicken-users] EINTR with self-pipe signal trampoline

[Jörg F . Wittenberger]

On Sep 29 2011, Alan Post wrote:

> On Thu, Sep 29, 2011 at 03:26:22PM +0200, Jörg F. Wittenberger wrote:
> > Signal handlers as they are in chicken might be problematic.
> > I can't find the message, but I recall a reply these days, which
> > informed me that it's true that chicken interrupt handlers are
> > in fact in a restricted dialect of Scheme: they can not allocate memory.
>
> I'm not sure how one would write a signal handler in chicken that
> doesn't allocate memory.  It seems even relatively primitive signal
> handlers, like my example case, do so:

Neither I am.  That's why I have the problem with the signal handlers.
I tried to do the textbook solution: just unlock a mutex in the signal
handler.  This would still not work for sure (though it does work for
quite some time in practice, but that doesn't help in reality).

>  (file-write output-pipe (string (integer->char signum))))
>
> I count that as two boxing operations, one that might not be doable

So do I.

In Chicken, all memory is initially allocated by moving the stack pointer
to make room for the object.  Upon minor gc those objects are moved
from the initial position (called nursery in chicken slang) to the heap.

That's why signal handlers have the problem, as I tried to explain in
the last message: they are run just when space is tight.

Moving them to the end of the gc (C_reclaim) *should* *probably* not
hurt.  Except that we *will* see a larger latency.

However my attempts to do so are not yet good enough.

> Given that a thread or a signal handler get their own stacks, and
> that Chicken uses the stack as a first-generation semispace/nursery,
> I'm not sure why conceptually one couldn't just execute the runtime
> inside a signal handler.

I'm afraid I'm not prepared to answer here.

> > Attempt work around: defer the signal even more: until next schedule
> > time.  I'm not yet satisfied with that solution.  (But at least it
> > allows me to run arbitrary code in the signal handler.)
> > (I intended so far to try whether it would be better to run it close
> > to the finalizers; that is at the end of garbage collection.
> > But that again is just an experiment TBD.)
>
> Interesting approach.  In conversation with you, I have determined
> that what has to happen to preserve the execution model is that
> signals are delivered before a syscall is performed.  It appears to
> me right now that any time at all between a return from a syscall
> and the next syscall are fine for signal delivery--that leaves a lot
> of room.

That might be the weakness of my attempt work around!  Thanks for the hint.

I'll try that next.  (As soon as I'm done testing your signaction patch,
which just finished to compile.)