used LIBTHREAD_1_0 as its version definition, but now needs
to define its symbols in the same namespace used by libc.
The compatibility hooks allows you to use libraries and
binaries built and linked to libpthread before libc was
built with symbol versioning. The shims can be removed if
libpthread is given a version bump.
Reviewed by: davidxu
* Add posix_memalign().
* Move calloc() from calloc.c to malloc.c. Add a calloc() implementation in
rtld-elf in order to make the loader happy (even though calloc() isn't
used in rtld-elf).
* Add _malloc_prefork() and _malloc_postfork(), and use them instead of
directly manipulating __malloc_lock.
Approved by: phk, markm (mentor)
functions in the child after a fork() from a threaded process,
use __sys_setprocmask() rather than setprocmask() to keep our
signal handling sane. Without this fix, signals are essentially
ignored in said child and things such as protection violations
result in an endless busy loop.
Reviewed by: deischen
o Don't reinitialise the atfork() handler list in the child. We
are meant to call the child handler, and on subsequent fork()s
should call all three functions as normal.
o Don't reinitialise the thread specific keyed data in the
child after a fork. Applications may require this for context.
o Reinitialise curthread->tlflags after removing ourselves from
(and reinitialising) the various internal thread lists.
o Reinitialise __malloc_lock in the child after fork() (to balance
our explicitly taking the lock prior to the fork()).
With these changes, it is possible to enable the NOTYET code in
thr_kern.c to allow the use of non-async-safe functions after
fork()ing from a threaded program.
Reviewed by: Daniel Eischen <deischen@freebsd.org>
[_malloc_lock reinitialisation has since been moved to avoid polluting the
!NOTYET code]
Like on libthr, there is an i386_set_gsbase() stub implementation here
to avoid libc.so.5 issues. This should likely be a weak symbol and I
expect this will be fixed soon.
Approved by: re
the lock is held by other thread, but not when nobody owns it. According
to deischen@, this part of code will never be hit in our threads
library, since it does not use locks without wait/wakeup functions.
Spotted by: mingyanguo via ChinaUnix.net forum
Reviewed by: deischen
changed to use the statclock. Make sure we calculate the value
of a tick correctly in userland.
Noticed by: Kazuaki Oda <kaakun at highway dot ne dot jp>
signals instead of having more intricate knowledge of thread state
within signal handling.
Simplify signal code because of above (by David Xu).
Use macros for libpthread usage of pthread_cleanup_push() and
pthread_cleanup_pop(). This removes some instances of malloc()
and free() from the semaphore and pthread_once() implementations.
When single threaded and forking(), make sure that the current
thread's signal mask is inherited by the forked thread.
Use private mutexes for libc and libpthread. Signals are
deferred while threads hold private mutexes. This fix also
breaks www/linuxpluginwrapper; a patch that fixes it is at
http://people.freebsd.org/~deischen/kse/linuxpluginwrapper.diff
Fix race condition in condition variables where handling a
signal (pthread_kill() or kill()) may not see a wakeup
(pthread_cond_signal() or pthread_cond_broadcast()).
In collaboration with: davidxu
packages expect and seems to be most correct according to the slightly-
ambiguous standards.
MFC after: 1 month
Corroborated by: POSIX <http://tinyurl.com/4uvub>
Reviewed by: silence on threads@
