[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
libpthread status report
From: |
Neal H. Walfield |
Subject: |
libpthread status report |
Date: |
Tue, 17 May 2005 11:47:40 +0100 |
User-agent: |
Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI) |
I've run the semaphore and thread parts of posixtestsuite 1.5.0 (with
a bunch of patches because a number of their tests are not POSIX
compliant) against our libpthread. We pass most tests. Here are the
major failings.
- signal handling
POSIX signal handling is completely broken (both kill and
pthread_kill). signals are delivered to the wrong threads, etc.
This requires investigation.
Also, pthread_kill does not correctly test if signal number is
valid.
- cancellation
Cancellation is not fully integrated into libc. For example, sleep
needs to be a cancellation point.
There is a bug in pthread_once. POSIX says: "if init_routine is a
cancellation point and is canceled, the effect on once_control shall
be as if pthread_once() was never called."
- pthread_atfork
Depends on support from glibc.
- user stacks
We allow user stacks but only if they are 2MB and a aligned on a 2MB
boundary (this is because TSD is stored at the base of the stack).
Programs would have a better chance of using this feature if we set
PTHREAD_STACK_MIN to 2MB but there are still alignment issues. If
we set it to about 4MB, we could just find the lowest address that
is a multiple of 2MB and use that as the base. It would cost a bit
of virtual address space but shouldn't be too bad. On the other
hand, we haven't encountered a program that relies on this feature.
- process shared synchronization
We have no pshared support for mutexes etc. I could come up with a
hack here such as busy waiting on the memory but again, no programs
have required this.
- shm_open and shm_unlink
Unsupported, however, most applications seem to use anonymous
semaphores. To support them we would need to support the pshared
attribute.
- <limits.h>
There are various limits which need to be defined by <limits.h>,
e.g. PTHREAD_KEYS_MAX. We don't define them at all right now. As a
hack, we could define them in <pthread.h>.
These usually have sysconf equivalents. I don't think this can be
worked around in libpthread. I think we need support from glibc.
- scheduling
We don't support scheduling attributes, priority ceilings, etc.
The following failures were not specific to libpthread:
- clock_gettime
A large number of tests failed because we don't have clock_gettime.
glibc is supposed to provide this.
- RLIMIT_AS
glibc doesn't define it.
Thanks,
Neal
- libpthread status report,
Neal H. Walfield <=