This was commited some time ago.

Just a follow-up about the patch:

- Barry's tree is in goober:/devel/bdefreese/hurd-pthread3/hurd
- Note the code in urfs/pager.c: it looks inside the rwlock in an ugly
  way. It looks like it is just trying to wait for the read lock to be
  available, but not actually lock.
- Condition implications have to be implemented. Barry has written some
  code which isn't in the patch attached to this task, just in his tree
- Note that libpthread does already provide some compatibility stuff in
  cthread-compat, which provides a few cthread symbols. That is needed
  for glibc that itself uses a few cthread things, like mutexes.
- As Barry mentioned, there are some linking issues: when linking
  statically, the "ascii version" of libpthread.a needs to be used,
  i.e. not the binary but the linker script that adds undefined
  references to a few compatibility cthread functions. Else the
  initialization wouldn't be done and we'd get a __pthread_threads
  assertion failure. The Makefiles should be fixed so that this is
  correctly done.
- Also, remembemer when testing all of this to apply the TLS patch,
  e.g. the one available in the debian package, else it'll just fail.
- spinlocks should rather be just statically initialized instead of
  adding constructor functions.
- calls to pthread_spin_trylock should be fixed: Barry didn't notice
  that the returned value wasn't the same as in cthreads.

Currently the Hurd libraries and servers use cthreads for threading, which is what Mach provides.  To gain greater portability, the libraries and servers should be ported to pthreads (which we also have a mostly functional implementation for in the Hurd).  Work on this task had already started years ago (with patches for a number of libraries), but then stalled again.  (This work can be made available.)

This task involves going through the source files for changing the cthreads calls to pthread ones, taking care for more difficult situations that can not be mapped one to one and finally (or incrementally where possible) testing the results.  Perhaps there will also be some bug hunting / fixing in our pthread implementation to be done.