blob: 73a139beb639e25f976f8187cb9988a3bebb0e66 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
Deferred signals investigation
## Overview
This has interesting complications and can resolve unity problems.
## Current high level idea
Add a new config option or two that enables "deferred/safe signal handling"
- Introduce the concept of "exit points" in the JIT, places where we can handle state
- Sprinkle "exit points" around in blocks in such a way that there is a bounded time between them
- Modify signal setters to block all signals on signals entry
- Modify signal handlers to resume JIT execution up to the next "exit point", and then handle the signal
- Edge cases: signals on syscalls, signals in non-jit code
- Add a signal torture test or two to our tests
## Other related ideas
- Add signal safe mode for all locks
## Curent low level ideas for first implementation
- use `ldb/stb [ctx-1], #0` + a guard page before the context for low cost handling of "should we exit from exit point" checks
(Description updated by @skmp)
|