bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[task #5487] cthreads -> pthreads


From: Samuel Thibault
Subject: [task #5487] cthreads -> pthreads
Date: Mon, 30 Mar 2009 20:37:58 +0000
User-agent: w3m/0.5.2

Follow-up Comment #4, task #5487 (project hurd):

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.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/task/?5487>

_______________________________________________
  Message posté via/par Savannah
  http://savannah.gnu.org/





reply via email to

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