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.)
_______________________________________________
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
