about summary refs log tree commit diff
path: root/src/thread/pthread_create.c
Commit message (Collapse)AuthorAgeFilesLines
* fix false ownership of stdio FILEs due to tid reuseRich Felker2014-08-231-0/+2
| | | | | | | | | | | | | this is analogous commit fffc5cda10e0c5c910b40f7be0d4fa4e15bb3f48 which fixed the corresponding issue for mutexes. the robust list can't be used here because the locks do not share a common layout with mutexes. at some point it may make sense to simply incorporate a mutex object into the FILE structure and use it, but that would be a much more invasive change, and it doesn't mesh well with the current design that uses a simpler code path for internal locking and pulls in the recursive-mutex-like code when the flockfile API is used explicitly.
* fix use of uninitialized memory with application-provided thread stacksRich Felker2014-08-221-0/+2
| | | | | | | | | | the subsequent code in pthread_create and the code which copies TLS initialization images to the new thread's TLS space assume that the memory provided to them is zero-initialized, which is true when it's obtained by pthread_create using mmap. however, when the caller provides a stack using pthread_attr_setstack, pthread_create cannot make any assumptions about the contents. simply zero-filling the relevant memory in this case is the simplest and safest fix.
* enable private futex for process-local robust mutexesRich Felker2014-08-161-0/+3
| | | | | | | | | | | | | | | | | | | | | | the kernel always uses non-private wake when walking the robust list when a thread or process exits, so it's not able to wake waiters listening with the private futex flag. this problem is solved by doing the equivalent in userspace as the last step of pthread_exit. care is taken to remove mutexes from the robust list before unlocking them so that the kernel will not attempt to access them again, possibly after another thread locks them. this removal code can treat the list as singly-linked, since no further code which would add or remove items is able to run at this point. moreover, the pending pointer is not needed since the mutexes being unlocked are all process-local; in the case of asynchronous process termination, they all cease to exist. since a process-local robust mutex cannot come into existence without a call to pthread_mutexattr_setrobust in the same process, the code for userspace robust list processing is put in that source file, and a weak alias to a dummy function is used to avoid pulling in this bloat as part of pthread_exit in static-linked programs.
* work around constant folding bug 61144 in gcc 4.9.0 and 4.9.1Rich Felker2014-07-161-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | previously we detected this bug in configure and issued advice for a workaround, but this turned out not to work. since then gcc 4.9.0 has appeared in several distributions, and now 4.9.1 has been released without a fix despite this being a wrong code generation bug which is supposed to be a release-blocker, per gcc policy. since the scope of the bug seems to affect only data objects (rather than functions) whose definitions are overridable, and there are only a very small number of these in musl, I am just changing them from const to volatile for the time being. simply removing the const would be sufficient to make gcc 4.9.1 work (the non-const case was inadvertently fixed as part of another change in gcc), and this would also be sufficient with 4.9.0 if we forced -O0 on the affected files or on the whole build. however it's cleaner to just remove all the broken compiler detection and use volatile, which will ensure that they are never constant-folded. the quality of a non-broken compiler's output should not be affected except for the fact that these objects are no longer const and thus possibly add a few bytes to data/bss. this change can be reconsidered and possibly reverted at some point in the future when the broken gcc versions are no longer relevant.
* eliminate use of cached pid from thread structureRich Felker2014-07-051-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | the main motivation for this change is to remove the assumption that the tid of the main thread is also the pid of the process. (the value returned by the set_tid_address syscall was used to fill both fields despite it semantically being the tid.) this is historically and presently true on linux and unlikely to change, but it conceivably could be false on other systems that otherwise reproduce the linux syscall api/abi. only a few parts of the code were actually still using the cached pid. in a couple places (aio and synccall) it was a minor optimization to avoid a syscall. caching could be reintroduced, but lazily as part of the public getpid function rather than at program startup, if it's deemed important for performance later. in other places (cancellation and pthread_kill) the pid was completely unnecessary; the tkill syscall can be used instead of tgkill. this is actually a rather subtle issue, since tgkill is supposedly a solution to race conditions that can affect use of tkill. however, as documented in the commit message for commit 7779dbd2663269b465951189b4f43e70839bc073, tgkill does not actually solve this race; it just limits it to happening within one process rather than between processes. we use a lock that avoids the race in pthread_kill, and the use in the cancellation signal handler is self-targeted and thus not subject to tid reuse races, so both are safe regardless of which syscall (tgkill or tkill) is used.
* add locale frameworkRich Felker2014-07-021-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | this commit adds non-stub implementations of setlocale, duplocale, newlocale, and uselocale, along with the data structures and minimal code needed for representing the active locale on a per-thread basis and optimizing the common case where thread-local locale settings are not in use. at this point, the data structures only contain what is necessary to represent LC_CTYPE (a single flag) and LC_MESSAGES (a name for use in finding message translation files). representation for the other categories will be added later; the expectation is that a single pointer will suffice for each. for LC_CTYPE, the strings "C" and "POSIX" are treated as special; any other string is accepted and treated as "C.UTF-8". for other categories, any string is accepted after being truncated to a maximum supported length (currently 15 bytes). for LC_MESSAGES, the name is kept regardless of whether libc itself can use such a message translation locale, since applications using catgets or gettext should be able to use message locales libc is not aware of. for other categories, names which are not successfully loaded as locales (which, at present, means all names) are treated as aliases for "C". setlocale never fails. locale settings are not yet used anywhere, so this commit should have no visible effects except for the contents of the string returned by setlocale.
* simplify errno implementationRich Felker2014-06-101-1/+0
| | | | | | | | | | | | | | | the motivation for the errno_ptr field in the thread structure, which this commit removes, was to allow the main thread's errno to keep its address when lazy thread pointer initialization was used. &errno was evaluated prior to setting up the thread pointer and stored in errno_ptr for the main thread; subsequently created threads would have errno_ptr pointing to their own errno_val in the thread structure. since lazy initialization was removed, there is no need for this extra level of indirection; __errno_location can simply return the address of the thread's errno_val directly. this does cause &errno to change, but the change happens before entry to application code, and thus is not observable.
* replace all remaining internal uses of pthread_self with __pthread_selfRich Felker2014-06-101-2/+2
| | | | | | | | | | prior to version 1.1.0, the difference between pthread_self (the public function) and __pthread_self (the internal macro or inline function) was that the former would lazily initialize the thread pointer if it was not already initialized, whereas the latter would crash in this case. since lazy initialization is no longer supported, use of pthread_self no longer makes sense; it simply generates larger, slower code.
* fix pointer type mismatch and misplacement of constRich Felker2014-03-241-2/+2
|
* always initialize thread pointer at program startRich Felker2014-03-241-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | this is the first step in an overhaul aimed at greatly simplifying and optimizing everything dealing with thread-local state. previously, the thread pointer was initialized lazily on first access, or at program startup if stack protector was in use, or at certain random places where inconsistent state could be reached if it were not initialized early. while believed to be fully correct, the logic was fragile and non-obvious. in the first phase of the thread pointer overhaul, support is retained (and in some cases improved) for systems/situation where loading the thread pointer fails, e.g. old kernels. some notes on specific changes: - the confusing use of libc.main_thread as an indicator that the thread pointer is initialized is eliminated in favor of an explicit has_thread_pointer predicate. - sigaction no longer needs to ensure that the thread pointer is initialized before installing a signal handler (this was needed to prevent a situation where the signal handler caused the thread pointer to be initialized and the subsequent sigreturn cleared it again) but it still needs to ensure that implementation-internal thread-related signals are not blocked. - pthread tsd initialization for the main thread is deferred in a new manner to minimize bloat in the static-linked __init_tp code. - pthread_setcancelstate no longer needs special handling for the situation before the thread pointer is initialized. it simply fails on systems that cannot support a thread pointer, which are non-conforming anyway. - pthread_cleanup_push/pop now check for missing thread pointer and nop themselves out in this case, so stdio no longer needs to avoid the cancellable path when the thread pointer is not available. a number of cases remain where certain interfaces may crash if the system does not support a thread pointer. at this point, these should be limited to pthread interfaces, and the number of such cases should be fewer than before.
* omit CLONE_PARENT flag to clone in pthread_createRich Felker2013-09-161-1/+1
| | | | | | | | CLONE_PARENT is not necessary (CLONE_THREAD provides all the useful parts of it) and Linux treats CLONE_PARENT as an error in certain situations, without noticing that it would be a no-op due to CLONE_THREAD. this error case prevents, for example, use of a multi-threaded init process and certain usages with containers.
* use symbolic names for clone flags in pthread_createRich Felker2013-09-161-2/+5
|
* support configurable page size on mips, powerpc and microblazeSzabolcs Nagy2013-09-151-0/+1
| | | | | | | | | | | | | | | | PAGE_SIZE was hardcoded to 4096, which is historically what most systems use, but on several archs it is a kernel config parameter, user space can only know it at execution time from the aux vector. PAGE_SIZE and PAGESIZE are not defined on archs where page size is a runtime parameter, applications should use sysconf(_SC_PAGE_SIZE) to query it. Internally libc code defines PAGE_SIZE to libc.page_size, which is set to aux[AT_PAGESZ] in __init_libc and early in __dynlink as well. (Note that libc.page_size can be accessed without GOT, ie. before relocations are done) Some fpathconf settings are hardcoded to 4096, these should be actually queried from the filesystem using statfs.
* transition to using functions for internal signal blocking/restoringRich Felker2013-04-261-8/+5
| | | | | | | | | | there are several reasons for this change. one is getting rid of the repetition of the syscall signature all over the place. another is sharing the constant masks without costly GOT accesses in PIC. the main motivation, however, is accurately representing whether we want to block signals that might be handled by the application, or all signals.
* prevent code from running under a thread id which already gave ESRCHRich Felker2013-04-261-1/+7
|
* fix clobbering of signal mask when creating thread with sched attributesRich Felker2013-04-261-1/+1
| | | | this was simply a case of saving the state in the wrong place.
* make last thread's pthread_exit give exit(0) a consistent stateRich Felker2013-04-261-3/+13
| | | | | the previous few commits ended up leaving the thread count and signal mask wrong for atexit handlers and stdio cleanup.
* use atomic decrement rather than cas in pthread_exit thread countRich Felker2013-04-261-4/+1
| | | | | | now that blocking signals prevents any application code from running while the last thread is exiting, the cas logic is no longer needed to prevent decrementing below zero.
* add comments on some of the pthread_exit logicRich Felker2013-04-261-2/+15
|
* always block signals in pthread_exit before decrementing thread countRich Felker2013-04-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | the thread count (1+libc.threads_minus_1) must always be greater than or equal to the number of threads which could have application code running, even in an async-signal-safe sense. there is at least one dangerous race condition if this invariant fails to hold: dlopen could allocate too little TLS for existing threads, and a signal handler running in the exiting thread could claim the allocated TLS for itself (via __tls_get_addr), leaving too little for the other threads it was allocated for and thereby causing out-of-bounds access. there may be other situations where it's dangerous for the thread count to be too low, particularly in the case where only one thread should be left, in which case locking may be omitted. however, all such code paths seem to arise from undefined behavior, since async-signal-unsafe functions are not permitted to be called from a signal handler that interrupts pthread_exit (which is itself async-signal-unsafe). this change may also simplify logic in __synccall and improve the chances of making __synccall async-signal-safe.
* fix type error in pthread_create, introduced with pthread_getattr_npRich Felker2013-04-061-1/+1
|
* implement pthread_getattr_npRich Felker2013-03-311-2/+8
| | | | | | this function is mainly (purely?) for obtaining stack address information, but we also provide the detach state since it's easy to do anyway.
* remove __SYSCALL_SSLEN arch macro in favor of using public _NSIGRich Felker2013-03-261-5/+5
| | | | | | | | | | | | | | the issue at hand is that many syscalls require as an argument the kernel-ABI size of sigset_t, intended to allow the kernel to switch to a larger sigset_t in the future. previously, each arch was defining this size in syscall_arch.h, which was redundant with the definition of _NSIG in bits/signal.h. as it's used in some not-quite-portable application code as well, _NSIG is much more likely to be recognized and understood immediately by someone reading the code, and it's also shorter and less cluttered. note that _NSIG is actually 65/129, not 64/128, but the division takes care of throwing away the off-by-one part.
* fix stale locks left behind when pthread_create failsRich Felker2013-02-011-3/+6
| | | | this bug seems to have been around a long time.
* if pthread_create fails, it must not attempt mmap if there is no mappingRich Felker2013-02-011-1/+1
| | | | | this bug was introduced when support for application-provided stacks was originally added.
* pthread stack treatment overhaul for application-provided stacks, etc.Rich Felker2013-02-011-17/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the main goal of these changes is to address the case where an application provides a stack of size N, but TLS has size M that's a significant portion of the size N (or even larger than N), thus giving the application less stack space than it expected or no stack at all! the new strategy pthread_create now uses is to only put TLS on the application-provided stack if TLS is smaller than 1/8 of the stack size or 2k, whichever is smaller. this ensures that the application always has "close enough" to what it requested, and the threshold is chosen heuristically to make sure "sane" amounts of TLS still end up in the application-provided stack. if TLS does not fit the above criteria, pthread_create uses mmap to obtain space for TLS, but still uses the application-provided stack for actual call frame stack. this is to avoid wasting memory, and for the sake of supporting ugly hacks like garbage collection based on assumptions that the implementation will use the provided stack range. in order for the above heuristics to ever succeed, the amount of TLS space wasted on POSIX TSD (pthread_key_create based) needed to be reduced. otherwise, these changes would preclude any use of pthread_create without mmap, which would have serious memory usage and performance costs for applications trying to create huge numbers of threads using pre-allocated stack space. the new value of PTHREAD_KEYS_MAX is the minimum allowed by POSIX, 128. this should still be plenty more than real-world applications need, especially now that C11/gcc-style TLS is now supported in musl, and most apps and libraries choose to use that instead of POSIX TSD when available. at the same time, PTHREAD_STACK_MIN has been decreased. it was originally set to PAGE_SIZE back when there was no support for TLS or application-provided stacks, and requests smaller than a whole page did not make sense. now, there are two good reasons to support requests smaller than a page: (1) applications could provide pre-allocated stacks smaller than a page, and (2) with smaller stack sizes, stack+TLS+TSD can all fit in one page, making it possible for applications which need huge numbers of threads with minimal stack needs to allocate exactly one page per thread. the new value of PTHREAD_STACK_MIN, 2k, is aligned with the minimum size for sigaltstack.
* add support for thread scheduling (POSIX TPS option)Rich Felker2012-11-111-0/+29
| | | | | | | | | | linux's sched_* syscalls actually implement the TPS (thread scheduling) functionality, not the PS (process scheduling) functionality which the sched_* functions are supposed to have. omitting support for the PS option (and having the sched_* interfaces fail with ENOSYS rather than omitting them, since some broken software assumes they exist) seems to be the only conforming way to do this on linux.
* clean up sloppy nested inclusion from pthread_impl.hRich Felker2012-11-081-0/+1
| | | | | | | | | | | | | | this mirrors the stdio_impl.h cleanup. one header which is not strictly needed, errno.h, is left in pthread_impl.h, because since pthread functions return their error codes rather than using errno, nearly every single pthread function needs the errno constants. in a few places, rather than bringing in string.h to use memset, the memset was replaced by direct assignment. this seems to generate much better code anyway, and makes many functions which were previously non-leaf functions into leaf functions (possibly eliminating a great deal of bloat on some platforms where non-leaf functions require ugly prologue and/or epilogue).
* add support for TLS variant I, presently needed for arm and mipsRich Felker2012-10-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | despite documentation that makes it sound a lot different, the only ABI-constraint difference between TLS variants II and I seems to be that variant II stores the initial TLS segment immediately below the thread pointer (i.e. the thread pointer points to the end of it) and variant I stores the initial TLS segment above the thread pointer, requiring the thread descriptor to be stored below. the actual value stored in the thread pointer register also tends to have per-arch random offsets applied to it for silly micro-optimization purposes. with these changes applied, TLS should be basically working on all supported archs except microblaze. I'm still working on getting the necessary information and a working toolchain that can build TLS binaries for microblaze, but in theory, static-linked programs with TLS and dynamic-linked programs where only the main executable uses TLS should already work on microblaze. alignment constraints have not yet been heavily tested, so it's possible that this code does not always align TLS segments correctly on archs that need TLS variant I.
* fix overlap of thread stacks with thread tls segmentsRich Felker2012-10-141-2/+1
|
* clean up and refactor program initializationRich Felker2012-10-071-1/+1
| | | | | | | | | | | | | | | the code in __libc_start_main is now responsible for parsing auxv, rather than duplicating the parsing all over the place. this should shave off a few cycles and some code size. __init_libc is left as an external-linkage function despite the fact that it could be static, to prevent it from being inlined and permanently wasting stack space when main is called. a few other minor changes are included, like eliminating per-thread ssp canaries (they were likely broken when combined with certain dlopen usages, and completely unnecessary) and some other unnecessary checks. since this code gets linked into every program, it should be as small and simple as possible.
* support for TLS in dynamic-loaded (dlopen) modulesRich Felker2012-10-051-10/+8
| | | | | | | | | | | | | | | | | | | | | unlike other implementations, this one reserves memory for new TLS in all pre-existing threads at dlopen-time, and dlopen will fail with no resources consumed and no new libraries loaded if memory is not available. memory is not immediately distributed to running threads; that would be too complex and too costly. instead, assurances are made that threads needing the new TLS can obtain it in an async-signal-safe way from a buffer belonging to the dynamic linker/new module (via atomic fetch-and-add based allocator). I've re-appropriated the lock that was previously used for __synccall (synchronizing set*id() syscalls between threads) as a general pthread_create lock. it's a "backwards" rwlock where the "read" operation is safe atomic modification of the live thread count, which multiple threads can perform at the same time, and the "write" operation is making sure the count does not increase during an operation that depends on it remaining bounded (__synccall or dlopen). in static-linked programs that don't use __synccall, this lock is a no-op and has no cost.
* TLS (GNU/C11 thread-local storage) support for static-linked programsRich Felker2012-10-041-5/+18
| | | | | | | | | | | | | the design for TLS in dynamic-linked programs is mostly complete too, but I have not yet implemented it. cost is nonzero but still low for programs which do not use TLS and/or do not use threads (a few hundred bytes of new code, plus dependency on memcpy). i believe it can be made smaller at some point by merging __init_tls and __init_security into __libc_start_main and avoiding duplicate auxv-parsing code. at the same time, I've also slightly changed the logic pthread_create uses to allocate guard pages to ensure that guard pages are not counted towards commit charge.
* further use of _Noreturn, for non-plain-C functionsRich Felker2012-09-061-2/+2
| | | | | | | | | | | | | | | | | | | note that POSIX does not specify these functions as _Noreturn, because POSIX is aligned with C99, not the new C11 standard. when POSIX is eventually updated to C11, it will almost surely give these functions the _Noreturn attribute. for now, the actual _Noreturn keyword is not used anyway when compiling with a c99 compiler, which is what POSIX requires; the GCC __attribute__ is used instead if it's available, however. in a few places, I've added infinite for loops at the end of _Noreturn functions to silence compiler warnings. presumably __buildin_unreachable could achieve the same thing, but it would only work on newer GCCs and would not be portable. the loops should have near-zero code size cost anyway. like the previous _Noreturn commit, this one is based on patches contributed by philomath.
* use restrict everywhere it's required by c99 and/or posix 2008Rich Felker2012-09-061-1/+1
| | | | | | | | to deal with the fact that the public headers may be used with pre-c99 compilers, __restrict is used in place of restrict, and defined appropriately for any supported compiler. we also avoid the form [restrict] since older versions of gcc rejected it due to a bug in the original c99 standard, and instead use the form *restrict.
* fix (hopefully) all hard-coded 8's for kernel sigset_t sizeRich Felker2012-08-091-2/+4
| | | | | | | | | | some minor changes to how hard-coded sets for thread-related purposes are handled were also needed, since the old object sizes were not necessarily sufficient. things have gotten a bit ugly in this area, and i think a cleanup is in order at some point, but for now the goal is just to get the code working on all supported archs including mips, which was badly broken by linux rejecting syscalls with the wrong sigset_t size.
* fix several locks that weren't updated right for new futex-based __lockRich Felker2012-07-121-3/+3
| | | | | | these could have caused memory corruption due to invalid accesses to the next field. all should be fixed now; I found the errors with fgrep -r '__lock(&', which is bogus since the argument should be an array.
* fix potential race condition in detached threadsRich Felker2012-07-111-2/+8
| | | | | | | after the thread unmaps its own stack/thread structure, the kernel, performing child tid clear and futex wake, could clobber a new mapping made at the same location as the just-removed thread's tid field. disable kernel clearing of child tid to prevent this.
* add pthread_attr_setstack interface (and get)Rich Felker2012-06-091-9/+13
| | | | | | | | | | | | | i originally omitted these (optional, per POSIX) interfaces because i considered them backwards implementation details. however, someone later brought to my attention a fairly legitimate use case: allocating thread stacks in memory that's setup for sharing and/or fast transfer between CPU and GPU so that the thread can move data to a GPU directly from automatic-storage buffers without having to go through additional buffer copies. perhaps there are other situations in which these interfaces are useful too.
* remove no-longer-needed unblocking of signals in pthread_createRich Felker2012-06-021-1/+0
| | | | | | | this action is now performed in pthread_self initialization; it must be performed there in case the first call to pthread_create is from a signal handler, in which case the old signal mask could be restored on return from the signal.
* simplify cancellation push/pop slightlyRich Felker2012-05-231-2/+2
| | | | | no need to pass unnecessary extra arguments on to the core code in pthread_create.c. this just wastes cycles and code bloat.
* make pthread stacks non-executableRich Felker2012-05-041-1/+1
| | | | | | | | | | | | | this change is necessary or pthread_create will always fail on security-hardened kernels. i considered first trying to make the stack executable and simply retrying without execute permissions when the first try fails, but (1) this would incur a serious performance penalty on hardened systems, and (2) having the stack be executable is just a bad idea from a security standpoint. if there is real-world "GNU C" code that uses nested functions with threads, and it can't be fixed, we'll have to consider other ways of solving the problem, but for now this seems like the best fix.
* overhaul SSP support to use a real canaryRich Felker2012-05-031-0/+1
| | | | | | | | | | | | | pthread structure has been adjusted to match the glibc/GCC abi for where the canary is stored on i386 and x86_64. it will need variants for other archs to provide the added security of the canary's entropy, but even without that it still works as well as the old "minimal" ssp support. eventually such changes will be made anyway, since they are also needed for GCC/C11 thread-local storage support (not yet implemented). care is taken not to attempt initializing the thread pointer unless the program actually uses SSP (by reference to __stack_chk_fail).
* fix pthread_cleanup_pop(1) crash in non-thread-capable, static-linked programsRich Felker2012-02-281-2/+0
|
* small fix for new pthread cleanup stuffRich Felker2012-02-091-1/+0
| | | | | | | even if pthread_create/exit code is not linked, run flag needs to be checked and cleanup function potentially run on pop. thus, move the code to the module that's always linked when pthread_cleanup_push/pop is used.
* replace bad cancellation cleanup abi with a sane oneRich Felker2012-02-091-16/+14
| | | | | | | | | | | | | | | | | | | | | | the old abi was intended to duplicate glibc's abi at the expense of being ugly and slow, but it turns out glib was not even using that abi except on non-gcc-compatible compilers (which it doesn't even support) and was instead using an exceptions-in-c/unwind-based approach whose abi we could not duplicate anyway without nasty dwarf2/unwind integration. the new abi is copied from a very old glibc abi, which seems to still be supported/present in current glibc. it avoids all unwinding, whether by sjlj or exceptions, and merely maintains a linked list of cleanup functions to be called from the context of pthread_exit. i've made some care to ensure that longjmp out of a cleanup function should work, even though it is not required to. this change breaks abi compatibility with programs which were using pthread cancellation, which is unfortunate, but that's why i'm making the change now rather than later. considering that most pthread features have not been usable until recently anyway, i don't see it as a major issue at this point.
* fix incorrect allocation failure check in pthread_createRich Felker2011-09-271-1/+1
| | | | | mmap returns MAP_FAILED not 0 because some idiot thought the ability to mmap the null pointer page would be a good idea...
* overhaul clone syscall wrappingRich Felker2011-09-181-5/+5
| | | | | | | | | | | | | | | | | | | | 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.
* pthread and synccall cleanup, new __synccall_wait opRich Felker2011-08-121-5/+1
| | | | | | | | | fix up clone signature to match the actual behavior. the new __syncall_wait function allows a __synccall callback to wait for other threads to continue without returning, so that it can resume action after the caller finishes. this interface could be made significantly more general/powerful with minimal effort, but i'll wait to do that until it's actually useful for something.
* further debloat cancellation handlersRich Felker2011-08-031-0/+13
| | | | | | | cleanup push and pop are also no-ops if pthread_exit is not reachable. this can make a big difference for library code which needs to protect itself against cancellation, but which is unlikely to actually be used in programs with threads/cancellation.
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-11-19 12:07:41 +0000