We'd highly prefer using std::thread here; but this won't let us configure the stack
size. macOS uses 512KiB size stacks for non-main threads, and musl defaults to 128k.
While Nix configures a 64MiB size for the main thread, this doesn't propagate to the
threads we launch here. It turns out, running the evaluator under an anemic stack of
0.5MiB has it overflow way too quickly. Hence, we have our own custom Thread struct.
This is caused, through several layers of absurdity, by runtime type
information of Nix things being invisible due to -fvisibility=hidden
inside n-e-j.
We don't have any idea why n-e-j has -fvisibility=hidden, since blame
says it's from the initial commit. It is plausible that it was some
ill-advised optimization but it's not sound.
The crash is caused by dynamic_cast<RootArgs *>(MyArgs *) failing, which
is in turn caused by the RTTI being invisible.
See: https://www.qt.io/blog/quality-assurance/one-way-dynamic_cast-across-library-boundaries-can-fail-and-how-to-fix-it
Fixes: lix-project/nix-eval-jobs#2
EvalState::error does not return an exception instance in lix, but an
exception *builder*. throwing this thing will not trigger any catches,
which then causes the worker process to die without reporting an error
to the collector. this confuses the collector and causes *it* to exit,
effectively breaking nix-eval-jobs for anything that has broken attrs.
While the previous style seems more sensible to me (the header names
are quite generic), the pkg-config definitions both from upstream Nix
and from Lix specify -I${includedir}/nix in CFLAGS rather than
-I${includedir}. This may be worth changing, but for now I want
nix-eval-jobs to work and this does what I want.
writeLine will throw a SysError exception, which obfuscates out-of-memory events where the eval worker is killed by the OS.
readLine is suffering from the same problem and will be handled in a subsequent commit.