pthread_cond_signal(), pthread_cond_broadcast(), and pthread_cond_timedwait().
Do not dump core in pthread_cond_timedwait() (due to a NULL pointer
dereference) if attempting to wait on an uninitialized condition variable.
PR: bin/18099
not have a user-supplied signal handler, when a signal is delivered, one
thread will receive the signal, and then the code reverts to having no
signal handler for the signal. This can leave the other sigwait()ing
threads stranded permanently if the signal is later ignored, or can result
in process termination when the process should have delivered the signal to
one of the threads in sigwait().
To fix this problem, maintain a count of sigwait()ers for each signal that
has no default signal handler. Use the count to correctly install/uninstall
dummy signal handlers.
Reviewed by: deischen
not allowed to return EINTR, but use of pthread_suspend_np() could cause
EINTR to be returned. To fix this, restructure pthread_suspend_np() so that
it does not interrupt a thread that is waiting on a mutex or condition, and
keep enough state around that pthread_resume_np() can fix things up
afterwards.
Reviewed by: deischen
thread waiting on an event (I/O, condvar, etc) will, when resumed using
pthread_resume_np, return with EINTR. For example, suspending and resuming
a thread blocked on read() will not requeue the thread for the read, but
will return -1 with errno = EINTR. If the suspended thread is in a critical
region, the thread is suspended as soon as it leaves the critical region.
Fix a bogon in pthread_kill() where a signal was being delivered twice
to threads waiting in sigwait().
Reported by (suspend/resume bug): jdp
Reviewed by: jasone
returning the error directly.
For sem_post(), make sure that the correct thread is woken up. This has
unfortunate performance implications, but is necessary for POSIX compliance.
Approved by: jkh
just use _foo() <-- foo(). In the case of a libpthread that doesn't do
call conversion (such as linuxthreads and our upcoming libpthread), this
is adequate. In the case of libc_r, we still need three names, which are
now _thread_sys_foo() <-- _foo() <-- foo().
Convert all internal libc usage of: aio_suspend(), close(), fsync(), msync(),
nanosleep(), open(), fcntl(), read(), and write() to _foo() instead of foo().
Remove all internal libc usage of: creat(), pause(), sleep(), system(),
tcdrain(), wait(), and waitpid().
Make thread cancellation fully POSIX-compliant.
Suggested by: deischen
are not supported by this implementation, and the error return values
from sem_init(), sem_open(), sem_close(), and sem_unlink() reflect this.
Approved by: jkh
signal handler. Explicitly check for jumps to anywhere other than the
current stack, since such jumps are undefined according to POSIX.
While we're at it, convert thread cancellation to use continuations, since
it's cleaner than the original cancellation code.
Avoid delivering a signal to a thread twice. This was a pre-existing bug,
but was likely unexposed until these other changes were made.
Defer signals generated by pthread_kill() so that they can be delivered on
the appropriate stack. deischen claims that this is unnecessary, which is
likely true, but without this change, pthread_kill() can cause undefined
priority queue states and/or PANICs in [sig|_]longjmp(), so I'm leaving
this in for now. To compile this code out and exercise the bug, define
the _NO_UNDISPATCH cpp macro. Defining _PTHREADS_INVARIANTS as well will
cause earlier crashes.
PR: kern/14685
Collaboration with: deischen
the case that a CPU hungry main thread is prevented from being preempted
due to a negative calculation of its time slice.
Reported by: Alexander Litvin <archer@lucky.net>
the initial thread). Instead, just leave an unmapped gap between thread
stacks and make sure that the thread stacks won't grow into these gaps,
simply by limiting the size of the stacks with the 'len' argument to
mmap(). This (if I understand correctly) reduces VM overhead
considerably.
Reviewed by: deischen
handler. Thread-to-thread signals (pthread_signal) are treated differently
than process signals; a pthread_signal can wakeup a blocked thread if
a signal handler is not installed for that signal.
Found by: ACE tests
o Cancellation flags were not getting properly set/cleared.
o Loops waiting for internal locks were not being exited
correctly by a cancelled thread.
o Minor spelling (cancelation -> cancellation) and formatting
corrections (missing tab).
Found by: tg
Reviewed by: jasone
o Don't call signal handlers with the signal handler access lock
held.
o Remove pending signals before calling signal handlers. If
pending signals were not removed prior to handling them,
invocation of the handler could cause the handler to be
called more than once for the same signal. Found by: JB
o When SIGCHLD arrives, wake up all threads in PS_WAIT_WAIT
(wait4).
PR: bin/15328
Reviewed by: jasone
Before this change, a signal was delivered to each thread that
didn't have the signal masked. Signals also improperly woke up
threads waiting on I/O. With this change, signals are now
handled in the following way:
o If a thread is waiting in a sigwait for the signal,
then the thread is woken up.
o If no threads are sigwait'ing on the signal and a
thread is in a sigsuspend waiting for the signal,
then the thread is woken up.
o In the case that no threads are waiting or suspended
on the signal, then the signal is delivered to the
first thread we find that has the signal unmasked.
o If no threads are waiting or suspended on the signal,
and no threads have the signal unmasked, then the signal
is added to the process wide pending signal set. The
signal will be delivered to the first thread that unmasks
the signal.
If there is an installed signal handler, it is only invoked
if the chosen thread was not in a sigwait.
In the case that multiple threads are waiting or suspended
on a signal, or multiple threads have the signal unmasked,
we wake up/deliver the signal to the first thread we find.
The above rules still apply.
Reported by: Scott Hess <scott@avantgo.com>
Reviewed by: jb, jasone
to use mmap(..., MAP_STACK, ...) on alpha too since that should work
now.
* Add hooks to allow GDB to access the internals of pthreads without
having to know the exact layout of struct pthread.
Reviewed by: deischen
eischen (Daniel Eischen) added wrappers to protect against cancled
threads orphaning internal resources.
the cancelability code is still a bit fuzzy but works for test
programs of my own, OpenBSD's and some examples from ORA's books.
add readdir_r to both libc and libc_r
add some 'const' attributes to function parameters
Reviewed by: eischen, jasone
-----------------------------
Most of the userland changes are in libc. For both the alpha
and the i386 setjmp has been changed to accomodate for the
new sigset_t. Internally, libc is mostly rewritten to use the
new syscalls. The exception is in compat-43/sigcompat.c
The POSIX thread library has also been rewritten to use the
new sigset_t. Except, that it currently only handles NSIG
signals instead of the maximum _SIG_MAXSIG. This should not
be a problem because current applications don't use any
signals higher than NSIG.
There are version bumps for the following libraries:
libdialog
libreadline
libc
libc_r
libedit
libftpio
libss
These libraries either a) have one of the modified structures
visible in the interface, or b) use sigset_t internally and
may cause breakage if new binaries are used against libraries
that don't have the sigset_t change. This not an immediate
issue, but will be as soon as applications start using the
new range to its fullest.
NOTE: libncurses already had an version bump and has not been
given one now.
NOTE: doscmd is a real casualty and has been disconnected for
the moment. Reconnection will eventually happen after
doscmd has been fixed. I'm aware that being the last one
to touch it, I'm automaticly promoted to being maintainer.
According to good taste this means that I will receive a
badge which either will be glued or mechanically stapled,
drilled or otherwise violently forced onto me :-)
NOTE: pcvt/vttest cannot be compiled with -traditional. The
change cause sys/types to be included along the way which
contains the const and volatile modifiers. I don't consider
this a solution, but more a workaround.
