Code review comment for lp:~raof/mir/no-ipc-on-compositor-threads

> Oh, dear.
>
> This is now running into poor interactions with fork(); specifically:
> Specifically:
> * After a fork() in a multithreaded program, the child can safely
> call only async-signal-safe functions (see signal-safety(7)) until
> such time as it calls execve(2).
>
> When running “make test”, we've got a single process executing all the tests;
> since the ThreadExecutor is now static, we now have a thread waiting around
> before we get to fork().

Ack. Objects with static duration can be problematic. :(

> This is why ptest doesn't fail; each test gets its own process...

I'm not convinced by that final reasoning: with ptest each test fixture gets its own process, but that still runs multiple tests (each of which may fork).