-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/29/2011 04:47 PM, Alan Post wrote:
> The way Chicken is currently implemented, any signal that arrives > during this time is discarded, which also makes me unhappy with this > situation. A lot of blood and tears were spilled over signal > handling on Unix to get to reliable signal delivery. I don't think > Chicken should implement unreliable signal delivery on top of a > reliable mechanism. I quite agree. > It seems that the thread-like nature of signal handling and the > thread-like nature of threading have been intermixed in the > scheduler, and this particular feature is at cross-purposes. So it seems... Signals should always end up being handled somewhere, unlessly explicitly set to be ignored; in that case, ignoring it IS handling it, but not otherwise. IIRC, signals are handled by setting a flag and poking the stack limit then returning. A GC is then invoked as soon as the interrupted thread tries to allocate memory, due to the poked stack limit, but the GC checks for the signal flag and goes off to do the signal if it has to. I presume that invoking the Chicken runtime inside the C-level signal handler is unsafe on account of Chicken wanting to call non-signal-safe C functions. I presume that allocating memory in a Chicken-level signal handler is "risky" as you might have actually been at or near the stack limit when the signal happened. I have not looked at the mechanism in code - just heard hearsay about it - - so please take this suggestion with a pinch of salt: 1) Have a (signal-safe) data structure containing pending signals. This might just be a bitmask, or if we want to be flash, a queue of generic pending "software interrupts" if there's uses for it other than signals. 2) C-level signal handlers poke an entry into the structure indicating the need to invoke a Chicken signal handler, and poke the stack limit [all of the above is basically what I think we already have] 3) The GC, invoked due to the stack limit being breached, checks for pending signals. If there are any, it resets the stack limit to what it was originally, then modifies the currently active continuation to a newly-allocated one that invokes a system procedure which executes all pending signals, then continues to the previous continuation; and returns. The normal stack limit needs to be set so that there will always, in the worst case, be enough space to allocate that extra continuation frame. If the system WAS at the edge of the stack when the signal(s) came in, it would then still be able to allocate the special continuation; execution of it would then almost instantly trigger a perfectly ordinary GC, and execution would continue as usual, executing the pending signal handler(s) then continuing with user code as before. That would give you low latency, unless the GC really needed to happen, in which case... well... it needs to happen before the handler can run. It would run signal handlers in the context of the currently executing thread when they happened, so to all intents and purposes it would be normal Chicken code, and the current thread would just temporarily dart off into signal handlers when required; I'm not sure what dynamic environment (in the parameters/current-output-port) they should be in; neither do I know how they are implemented in Chicken! Perhaps they should encapsulate a copy of the dynamic environment in place when the signal handler was registered, as the most hygienic option... > -Alan ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6El54ACgkQRgz/WHNxCGpebACfdxF+Fqb3OiEVJHoAaww3U23f inkAnRCPDl2dZhWrrdBODaBC8+rCDdHY =VjKl -----END PGP SIGNATURE----- _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users