summaryrefslogtreecommitdiff
path: root/src/stdio/tmpfile.c
diff options
context:
space:
mode:
authorRich Felker <dalias@aerifal.cx>2013-07-17 13:54:41 -0400
committerRich Felker <dalias@aerifal.cx>2013-07-17 13:54:41 -0400
commitb06dc6663989f8b3c141e439fe89036a44eb7552 (patch)
tree3abf92c0c69d7663804c4efe46d09ace5b8da8fc /src/stdio/tmpfile.c
parent3df0b66ee95c837496ae434ba7a2282d97ca71ef (diff)
downloadmusl-b06dc6663989f8b3c141e439fe89036a44eb7552.tar.gz
musl-b06dc6663989f8b3c141e439fe89036a44eb7552.tar.bz2
musl-b06dc6663989f8b3c141e439fe89036a44eb7552.tar.xz
musl-b06dc6663989f8b3c141e439fe89036a44eb7552.zip
make posix_spawn (and functions that use it) use CLONE_VFORK flag
this is both a minor scheduling optimization and a workaround for a difficult-to-fix bug in qemu app-level emulation. from the scheduling standpoint, it makes no sense to schedule the parent thread again until the child has exec'd or exited, since the parent will immediately block again waiting for it. on the qemu side, as regular application code running on an underlying libc, qemu cannot make arbitrary clone syscalls itself without confusing the underlying implementation. instead, it breaks them down into either fork-like or pthread_create-like cases. it was treating the code in posix_spawn as pthread_create-like, due to CLONE_VM, which caused horribly wrong behavior: CLONE_FILES broke the synchronization mechanism, CLONE_SIGHAND broke the parent's signals, and CLONE_THREAD caused the child's exec to end the parent -- if it hadn't already crashed. however, qemu special-cases CLONE_VFORK and emulates that with fork, even when CLONE_VM is also specified. this also gives incorrect semantics for code that really needs the memory sharing, but posix_spawn does not make use of the vm sharing except to avoid momentary double commit charge. programs using posix_spawn (including via popen) should now work correctly under qemu app-level emulation.
Diffstat (limited to 'src/stdio/tmpfile.c')
0 files changed, 0 insertions, 0 deletions