- 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.

OK I'm attaching my latest patch. I've taken zentons work and taken it all the way. Everything compiles but there are issues.

Static linking has issues. If I let the build system do it's thing, ext2fs and ext2fs --help return values however its linked to the binary libpthread. If I link against the ascii pthread in hurd/libpthread it either gives some goofy errors or hangs. For some reason I cannot get gdb to give me debugging symbols or it hangs even inside of gdb and I can't attach to the pid because ps also hangs.

I have added pt-cond-implies but it is not completed and neal thinks the code should be inlined anyway.

As far as I got it, Hurd-specific part of threads are very related with cancelation stuff. We really need hurd_condition_wait and hurd_thread_cancel or it would be possible to adapt Hurd to use pthread_thread_cancel?

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.