mirror of
https://codeberg.org/ziglang/zig.git
synced 2025-12-09 07:08:59 +00:00
3169f0529b
Today I found out that posix_spawn is trash. It's actually implemented on top of fork/exec inside of libc (or libSystem in the case of macOS). So, anything posix_spawn can do, we can do better. In particular, what we can do better is handle spawning of child processes that are potentially foreign binaries. If you try to spawn a wasm binary, for example, posix spawn does the following: * Goes ahead and creates a child process. * The child process writes "foo.wasm: foo.wasm: cannot execute binary file" to stderr (yes, it prints the filename twice). * The child process then exits with code 126. This behavior is indistinguishable from the binary being successfully spawned, and then printing to stderr, and exiting with a failure - something that is an extremely common occurrence. Meanwhile, using the lower level fork/exec will simply return ENOEXEC code from the execve syscall (which is mapped to zig error.InvalidExe). The posix_spawn behavior means the zig build runner can't tell the difference between a failure to run a foreign binary, and a binary that did run, but failed in some other fashion. This is unacceptable, because attempting to excecve is the proper way to support things like Rosetta. |
||
|---|---|---|
| .. | ||
| Cache | ||
| Cache.zig | ||
| CheckFileStep.zig | ||
| CheckObjectStep.zig | ||
| CompileStep.zig | ||
| ConfigHeaderStep.zig | ||
| EmulatableRunStep.zig | ||
| FmtStep.zig | ||
| InstallArtifactStep.zig | ||
| InstallDirStep.zig | ||
| InstallFileStep.zig | ||
| LogStep.zig | ||
| ObjCopyStep.zig | ||
| OptionsStep.zig | ||
| RemoveDirStep.zig | ||
| RunStep.zig | ||
| Step.zig | ||
| TranslateCStep.zig | ||
| WriteFileStep.zig | ||