[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] remove enable/disable interrupt flag

From: Alaric Snell-Pym
Subject: Re: [Chicken-users] remove enable/disable interrupt flag
Date: Thu, 29 Sep 2011 17:06:54 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110617 Thunderbird/3.1.11

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


- --
Alaric Snell-Pym
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


reply via email to

[Prev in Thread] Current Thread [Next in Thread]