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

[Alan Post]

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:

  (file-write output-pipe (string (integer->char signum))))

I count that as two boxing operations, one that might not be doable
on the stack (I don't know yet how Chicken Scheme allocates strings
and therefor whether it does so on the stack.  Then of course
whatever memory is required to traverse the sexpr--I don't know how
Chicken handles that yet either.

The objects allocated could be done in advance, as you know what
signal numbers you'll be receiving, but I've just assumed the
deferral mechanism for signals is done in part to allow memory to be
allocated inside them, because they're called in the main thread (or
some rough equivalent).

*C* signal handlers can't allocate memory, for sure--I'd consider it
poor form to do something in a Chicken signal handler that isn't
adviseable from a C signal handler, but the runtime environment
makes that boundary fuzzy, for me.


> I started to read into it.  I too, still don't understand all of the
> C_reclaim procedure.  But it's obvious that the interrupt handler
> is invoked at the begin of the garbage collection.  Wild guess:
> there is no memory available for allocation at that time.
> 

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.  There are things I'd forbid: no signals
delivered during GC, no GC in the signal handler, &c.  It may well
be nothing but hair all the way down, but architecturally I haven't
imagined anything to prevent it.

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

.i ko .e mi ze'aca kelgu'a (let's keep hacking),

-Alan
-- 
.i ma'a lo bradi cu penmi gi'e du