On Sun, May 12, 2019 at 4:46 AM Lassi Kortela <xxxxxx@lassi.io> wrote:

If you throw an exception from the signal handler, which thread is that
exception raised in? If we always run a Scheme signal handler in the
main thread, or let Unix pick a thread at random, in either case it can
be a different thread than the one that was running when we got the signal.

Agreed. Having read <http://250bpm.com/blog:12>, I now understand the issues better, so what I wrote last night is irrelevant. The problematic sequence of events is:

Thread A executes a system call.

An async signal occurs that has a signal handler.

The kernel returns to user mode and executes the Posix-level signal handler in thread B

The Posix signal handler enqueues a Scheme signal handler for later execution (in thread C?)

When the signal handler exits, thread A is resumed with errno = EINTR.

The Scheme runtime re-executes the system call on behalf of thread A.

Asynchronously, thread C runs the Scheme signal handler, at which point any non-local exit is irrelevant to thread A.

Is that a fair summary?

Don't read() and similar syscalls just return -1 bytes read and set
errno to EINTR? I wasn't aware that they'd return partial data when
interrupted by a signal.

You're right.

John Cowan http://vrici.lojban.org/~cowan xxxxxx@ccil.org

Almost all theorems are true, but almost all proofs have bugs.

--Paul Pedersen