diff options
author | Rich Felker <dalias@aerifal.cx> | 2013-07-17 13:54:41 -0400 |
---|---|---|
committer | Rich Felker <dalias@aerifal.cx> | 2013-07-17 13:54:41 -0400 |
commit | b06dc6663989f8b3c141e439fe89036a44eb7552 (patch) | |
tree | 3abf92c0c69d7663804c4efe46d09ace5b8da8fc /src/stdio/__lockfile.c | |
parent | 3df0b66ee95c837496ae434ba7a2282d97ca71ef (diff) | |
download | musl-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/__lockfile.c')
0 files changed, 0 insertions, 0 deletions