bug-hurd
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]