1.0.25.44: INTERRUPT-THREAD and timer improvements
The main thing accomplished by this commit is that it's finally
possible to use INTERRUPT-THREAD and TIMERS sanely:
- there is a per thread interruption queue, interruption are executed
in order of arrival
- the interruption has to explicitly enable interrupts with
WITH-INTERRUPTS if needed. In the absence of WITH-INTERRUPTS the
interruption itself is not interrupted and running out of stack is
not a problem.
- timers have an improved repeat mechanism
Implementation notes:
- INTERRUPT-THREAD is implemented on all platforms and builds (that
is, even without :SB-THREAD) by sending a signal to the current
thread (or process without thread). This allows us to hook into the
normal, interrupt deferral mechanism without having to commit OAOO
violations on the Lisp side. And it makes threaded, non-threaded
builds closer, hopefully easing testing.
- SIG_INTERRUPT_THREAD is SIGPIPE on all platforms. SIGPIPE is not
used in SBCL for its original purpose, instead it's for signalling a
thread that it should look at its interruption queue. The handler
(RUN_INTERRUPTION) just returns if there is nothing to do so it's
safe to receive spurious SIGPIPEs coming from the kernel.
- IN-INTERRUPTION does not unblock deferrables anymore, but arranges
for them to be unblocked when interrupts are enabled (see
*UNBLOCK-DEFERRABLES-ON-ENABLING-INTERRUPTS-P*).
- Thread interruption run wrapped in a (WITHOUT-INTERRUPTS
(ALLOW-WITH-INTERRUPTS ...)).
- Repeating timers reschedule themselves when they finished to the
current expiry time + repeat interval even if that's in the past.
Hence, a timer's schedule does not get shifted if it takes a long
time to run. If it takes more time than the repeat interval then it
may catch up on later invokations.
- Timers run wrapped in a (WITHOUT-INTERRUPTS (ALLOW-WITH-INTERRUPTS
...)) even in run in a new thread.
- Enable previously failing tests.
- Add more tests.
- Automatically unschedule repeating timers if they take up all the
CPU.
23 files changed: