| Age | Commit message (Collapse) | Author |
|
lib/libpthread/pthread_rwlock.c: revision 1.37 (patch)
lib/libpthread/pthread_misc.c: revision 1.16
lib/libpthread/pthread.c: revision 1.154
lib/libpthread/pthread_int.h: revision 1.98
lib/libpthread/pthread_cond.c: revision 1.66
lib/libpthread/pthread_mutex.c: revision 1.66
Rip out some very ambitious optimisations around pthread_mutex that are
don't buy much. This stuff is hard enough to get right in the kernel let
alone userspace, and I don't trust that it's right.
|
|
to the pthread tsd implementation when the main thread is created.
This corrects a problem where a process created keys before libpthread
was loaded (either from the libc constructor or because libpthread
was dlopened later). This fixes a problem with jemalloc which creates
keys in the constructor.
|
|
No functional change intended.
|
|
|
|
functions are used for destructors of thread_local objects.
If a pending destructor exists, prevent unloading of shared objects.
Introduce __dl_cxa_refcount interface for this purpose. When the last
reference is gone and the object has been dlclose'd before, the
unloading is finalized.
Ideally, __cxa_thread_atexit_impl wouldn't exist, but libstdc++ insists
on providing __cxa_thread_atexit as direct wrapper without further
patching.
|
|
|
|
complementary writable sysctl for the initial guard size of threads
created via pthread_create. Let the existing attribut accessors do the
right thing. Raise the default guard size for threads to 64KB.
|
|
of the thread library, because malloc uses pthread_foo_specific, and it will
end up initializing itself incorrectly.
|
|
NetBSD's PTHREAD_KEYS_MAX is set to 256, which is low compared to
other systems like Linux (1024) or MacOS X (512). As a result some
setups tested on Linux will exhibit problems on NetBSD because of
pthread_keys usage beyond the limit. This happens for instance on
Apache with various module loaded, and in this case no particular
developper can be blamed for going beyond the limit, since several
modules from different sources contribute to the problem.
This patch makes the limit conigurable through the PTHREAD_KEYS_MAX
environement variable. If undefined, the default remains unchanged
(256). In any case, the value cannot be lowered below POSIX-mandated
_POSIX_THREAD_KEYS_MAX (128).
While there:
- use EXIT_FAILURE instead of 1 when calling err(3) in libpthread.
- Reset _POSIX_THREAD_KEYS_MAX to POSIX mandated 128, instead of 256.
|
|
A concrete result is enabling unpatched libpthread to run on the
rumprun stacks (e.g. Xen and bare metal) with a non-NetBSD scheduler.
Those schedulers hook into the existing _lwp_frobnitz() NetBSD syscall
interfaces (well, "syscall" interfaces in that scenario ;)
More specifically about the change itself:
1) instead of calling _lwp_makecontext() followed by _lwp_create()
and passing the entry point in ucontext_t (MD) through the calls, roll
the calls into pthread__makelwp() and allow alternate implementations
for that MI interface.
2) allow compile-time overriding of __lwp_gettcb_fast() or
__lwp_getprivate_fast, which are inline and leak MD scheduler/thread
details into libpthread
Additionally, two small nits:
I) define LIB=pthread before including mk.conf so that it's possible
to test for LIB==pthread in mk.conf
II) make it possible to leave out pthread_cancelstub.c. This is required
by the current implementation of rumprun-posix (i.e. rumprun on
POSIX hosts) due to symbol collisions. It needs to be fixed properly
some day, but for now allows an almost-correct libpthread to run.
I am sure @justin will be happy to explain the details ;)
no change to NetBSD
tested: anita+atf
|
|
syscall directly.
|
|
- Fail if the dlopened libpthread does pthread_create(). From manu@
- Discussed at length in the mailing lists; approved by core@
- This was chosen as the least intrusive patch that will provide
the necessary functionality.
XXX: pullup to 6
|
|
|
|
|
|
|
|
|
|
|
|
(this is not entirely correct because it can return ENOMEM which is
not mentioned in the spec, but there are other places in pthread_create
whete ENOMEM is returned -- it at all, this should be fixed everywhere)
|
|
|
|
place as it is redundant.
|
|
which is the only thread lives in the child process.
The problem originally reported here:
https://bugs.ruby-lang.org/issues/6341
|
|
|
|
modifiable later. Only reuse the stack if it was allocated by libpthread
and if the expected thread size matches the current stack size.
|
|
don't bother with setting up a guard page. Otherwise, round up the size
to page size. Point stack inside the guarded area, without the guard
page. Fix size when mprotect failed.
|
|
|
|
-minor indentation fix
|
|
|
|
AT_STACKBASE is pointing to the start of the stack, which is the
upper limit on platforms where the stack grows down.
|
|
restrictions on the thread stack. Remove remaining parts of stackid.
|
|
debugging to avoid multiple td_open() mess.
|
|
|
|
- Update TCB for the initial thread in pthread__initthread, not
pthread__init to get it valid as soon as possible.
- Don't overwrite the pt_tls field in pthread__initthread.
- Don't deallocate pt_tls in pthread__scrubthread. This worked more by
chance than by design.
- Handle freeing the TLS area in pthread_create after removing the
thread instance from the dead queue.
|
|
|
|
_rtld_tls_allocate and _rtld_tls_free. libpthread uses this functions to
setup the thread private area of all new threads. ld.elf_so is
responsible for setting up the private area for the initial thread.
Similar functions are called from _libc_init for static binaries, using
dl_iterate_phdr to access the ELF Program Header.
Add test cases to exercise the different TLS storage models. Test cases
are compiled and installed on all platforms, but are skipped on
platforms not marked for TLS support.
This material is based upon work partially supported by
The NetBSD Foundation under a contract with Joerg Sonnenberger.
It is inspired by the TLS support in FreeBSD by Doug Rabson and the
clean ups of the DragonFly port of the original FreeBSD modifications.
|
|
|
|
|
|
the situation, I decided to commit it. There is an inherent problem
with ASLR and the way the pthread library is using the thread stack.
Our pthread library chooses that stack for each thread strategically
so that it can locate the location of the pthread struct for each
thread by masking the stack pointer and looking just below the red
zone it creates. Unfortunately with ASLR you get many random values
for the initial stack, and there are situations where the masked
stack base ends up below the base of the stack. (this happens on
x86 when the stack base happens to be 0x???02000 for example and
your mask is stackmask is 0xffe00000). To fix this, we detect the
pathological cases (this happens only in the main thread), allocate
more stack, and mprotect it appropriately. Then we stash the main
base and the main struct, so that when we look for the pthread
struct in pthread__id, we can special case the main thread.
Another way to work around the problem is unlimiting stacksize,
but the proper way is to use TLS to find the thread structure and
not to play games with the thread stacks.
|
|
|
|
|
|
instead of a function that may be going away. KNFify
|
|
|
|
to reuse, because if we lose the race with the kernel we are never going
to reuse any elements. Look in the whole list instead.
XXX: should be pulled up to 5.x
|
|
|
|
_lwp_makecontext are solved.
|
|
- Rely on _lwp_makecontext() to set up the thread identity register.
This is not currently done (a bug), nor does libpthread use the
threadreg yet. I'm doing this so it the code can be used by the
person working on TLS to verify that their threadreg code is working.
|
|
implementation:
-don't return a difference, this can overflow
-don't try to substract typed pointers which don't belong to the
same object, this gives undefined results
This fixes instabilities of programs which use more than a handful
of threads, eg spuriously failing pthread_join().
|
|
I guess not well enough.
|
|
XXX This must not be enabled by default because the LWP private mechanism
is reserved for TLS. It is provided only as a test/demo.
XXX Since ucontext_t does not contain the thread private variable, for a
short time after threads are created their thread specific data is unset.
If a signal arrives during that time we are screwed.
- No longer need pthread__osrev.
- Rearrange _lwp_ctl() calls slightly.
|
|
other systems. Allows poorly written applications to appear working. If you
are developing pthread apps please turn it on manually by setting the
environment variable.
|
|
|