summaryrefslogtreecommitdiff
path: root/src/thread/forkall.c
AgeCommit message (Collapse)AuthorLines
2012-05-22remove everything related to forkallRich Felker-68/+0
i made a best attempt, but the intended semantics of this function are fundamentally contradictory. there is no consistent way to handle ownership of locks when forking a multi-threaded process. the code could have worked by accident for programs that only used normal mutexes and nothing else (since they don't actually store or care about their owner), but that's about it. broken-by-design interfaces that aren't even in glibc (only solaris) don't belong in musl.
2011-09-18overhaul clone syscall wrappingRich Felker-0/+2
several things are changed. first, i have removed the old __uniclone function signature and replaced it with the "standard" linux __clone/clone signature. this was necessary to expose clone to applications anyway, and it makes it easier to port __clone to new archs, since it's now testable independently of pthread_create. secondly, i have removed all references to the ugly ldt descriptor structure (i386 only) from the c code and pthread structure. in places where it is needed, it is now created on the stack just when it's needed, in assembly code. thus, the i386 __clone function takes the desired thread pointer as its argument, rather than an ldt descriptor pointer, just like on all other sane archs. this should not affect applications since there is really no way an application can use clone with threads/tls in a way that doesn't horribly conflict with and clobber the underlying implementation's use. applications are expected to use clone only for creating actual processes, possibly with new namespace features and whatnot.
2011-08-12implement forkallRich Felker-0/+66
this is a "nonstandard" function that was "rejected" by POSIX, but nonetheless had its behavior documented in the POSIX rationale for fork. it's present on solaris and possibly some other systems, and duplicates the whole calling process, not just a single thread. glibc does not have this function. it should not be used in programs intending to be portable, but may be useful for testing, checkpointing, etc. and it's an interesting (and quite small) example of the usefulness of the __synccall framework originally written to work around deficiencies in linux's setuid syscall.