Zig Version
0.16.0
Steps to Reproduce and Observed Behavior
std.process.spawn(io, .{.start_suspended = true}) on latest Linux sends SIGSTOP not only to the newly forked process but also to the invoking process, which makes the option practically useless. The immediate cause for this is that it calls kill(0, SIGSTOP) instead of kill(getpid(), SIGSTOP), but even when that is fixed, spawn will just block indefinitely waiting for the execve.
Expected Behavior
The start_suspended mode is probably just incompatible with the current interface of process.spawn. Since reporting the result of the exec immediately is very convenient for most use-cases, the behavior of creating a forked-but-not-yet-execed process should probably be moved to a separate function (if we want to maintain it at all; I could use this for writing a debugger, but struggle to come up with any other application).
### Zig Version
0.16.0
### Steps to Reproduce and Observed Behavior
`std.process.spawn(io, .{.start_suspended = true})` on latest Linux sends `SIGSTOP` not only to the newly forked process but also to the invoking process, which makes the option practically useless. The immediate cause for this is that it calls `kill(0, SIGSTOP)` instead of `kill(getpid(), SIGSTOP)`, but even when that is fixed, `spawn` will just block indefinitely waiting for the execve.
### Expected Behavior
The `start_suspended` mode is probably just incompatible with the current interface of `process.spawn`. Since reporting the result of the exec immediately is very convenient for most use-cases, the behavior of creating a forked-but-not-yet-execed process should probably be moved to a separate function (if we want to maintain it at all; I could use this for writing a debugger, but struggle to come up with any other application).