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