v2: "canceling" blocking syscalls on macOS does not truly cancel them

[robbielyman]

it's not completely clear to me how important this issue is, but it is an issue.

for example, the CLI interface has a recurring call to read from stdin.
this call may be "canceled" on the event loop in two situations:
one, where the program is exiting due to some condition other than the user typing "quit" in the REPL,
and two, where the TUI interface is launched.
in each situation on macOS, the call to read is executing on a different thread, which stays blocked in that call.

there are two instances where this becomes an issue:
under normal execution, if any thread is blocked (say in read), calling seamstress.pool.deinit() will block too,
since it tries to join the thread.
strictly speaking, cleaning up the thread pool is not a prerequisite for exiting the program,
but i could see this becoming an issue if many zombie threads accumulate,
say in a hot-reload situation.

the other is that when running tests via zig build test, the test runner is run in "server" mode,
which appears to not exit whenever any test has active threads remaining?
it's not clear to me how this is accomplished, but it is true that if i delete the following lines in Seamstress.deinit

seamstress.pool.shutdown();
seamstress.pool.deinit();

the test runner will still fail to exit.

---

potential solutions include wrapping the call to read in a poll which includes a self-pipe for terminating the thread, or looking into alternate solutions for the event loop. might actually be time to read some of Node.js's source lol