Awesome comments.

> The pitfall is that when the program spawns a subprocess from a
> non-primordial thread.
> Since subprocess inherits the signal mask, it will block all signals.
>
> It is not as simple as unblock signals then call spawn(), since a signal
> may delivered
> between two calls.  Changing signal mask must be done after fork(),
> before exec().

I think it's necessary to design the spawn process facility to either
(1) take keyword arguments, or (2) use a not-yet-launched-process object
to set options. Then implementations can add their own keyword args /
object accessors to implement extra stuff.

The signal mask could be one such addition. But since the problem you
describe will hit all implementations with threads, maybe it would be
good to add as standard in the SRFI itself.

BTW, what happens if the forked child process receives a signal before
it has time to call exec?

> Using it in single-thread app is fine, but if it is used
> deep in some portable library, that library needs to be called with care.

Agree we should design the SRFI such that users can write reliable
libraries.