pthread types in C++ builds, attempt 2.
The problem with attempt 1 was making assumptions of what the MD
__cpu_simple_lock_t (declared volatile) looks like. To get a same type
except non-volatile, we change the MD type to __cpu_simple_lock_nv_t
and typedef __cpu_simple_lock_t as a volatile __cpu_simple_lock_nv_t.
IMO, __cpu_simple_lock_t should not be volatile at all, but changing it
now is too risky.
Fixes at least Rumprun w/ gcc 5.1/5.2. Furthermore, the mpd application
(and possibly others) will no longer require NetBSD-specific patches.
Tested: build.sh for i386, Rumprun for x86_64 w/ gcc 5.2.
Based on the patch from Christos in lib/49989.
__cpu_simple_lock_t (because it doesn't). Instead, use sizeof/alignof
with a struct { uchar[] }.
Fixes problem in previous commit, caught by Nick Hudson.
member initializer. This does not work for volatile types. Since C++
does not touch the guts of those types, redefine them as non-volatile.
Fixes libc++ compilation with g++ 5.1, as reported in PR lib/49989.
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
non-interlocked CAS in the fast unlock path -- it is unsafe to test for
the waiters-bit while the owner thread is running, we have to spin for
the owner or its state change to be sure about the presence of the bit.
Split off the logic into the pthread__mutex_setwaiters() routine.
This is a partial fix to the named lockup problem (also see PR/44756).
It seems there is another race which can be reproduced on faster CPUs.
has two parts:
- in pthread_cond_timedwait() if the thread we are trying to unpark
exited, retry the the _lwp_park call without it.
- pthread_mutex() was affecting errno since it is calling _lwp_park()
from pthread_mutex_lock_slow(). preserve the original errno.
Note that the example problem still causes an occassional deadlock on machines
with many CPUs and it is the same deadlock we observe with named.
after call pthread_condattr_setclock(CLOCK_MONOTONIC)
_lwp_park(2) expects a realtime clock, and it gets passed a monotonic
one. Since monotonic < real, it never sleeps. This patch adjusts
the monotonic clock to be a real one before it passes is to
_lwp_park(2). This is the minimal hacky fix and it will be fixed
properly in _lwp_park(2) in the future.
XXX: pullup to 6.
- 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
and pthread_{g,s}etspecific functions, to one that invalidates
values of keys in other threads when pthread_key_delete() is called.
This fixes chromium, which expects pthread_key_delete() to do
cleanup in all threads.
.Vt type var No = Dv INITIALIZER;
to provide examples of static initialization in SYNOPSIS section.
.Va macro does the wrong thing (check groff PostScript output) and the
need for .Pp kludge (now dropped) should have been an indication too.
While here move static initialization example to be right after the
declaration of *_init().
