Hello, Samuel,
On 04/17/2016 12:24 PM, Samuel Thibault wrote:
Hello,
Ok, but why not just fixing pthread_mutex_lock & such in our current
libpthread, instead of having yet another implementation? How are we
supposed to handle those three implementations: Neal's, nptl, and yours?
Ideally your reimplementation is perfect and we can throw away Neal's,
but nobody can be perfect when writing a pthread library (been there,
didn't do that ;) ), so I'm really not at ease with throwing away Neal's
implementation which we have fixed over years.
Samuel
The implementations for pthread objects (mutexes, condvars, etc) that
I have right now can be easily transplanted into the current lib without
much issue. I also have the implementation for what glibc calls
'low-level lock' i.e. a wrapper around something like futex. That can be
integrated into glibc to replace spin locks where needed as well.
The reason why I chose to rewrite libpthread is because there are many
things that I disagree with the current one. For instance:
- Instead of creating thread descriptors with malloc, I place them at the
top of the stack.
- Instead of using a TLS slot for the current thread, I use a field in the TCB.
- Instead of looking up the signal state with 'mach_thread_self', I have it
cached inside the thread descriptor.
Those are some of the many differences I can think of right now. I don't mean
to disparage Neal's work; I simply think that since we have a better tool for
synchronization, it's time to revamp libpthread :)
In any case, I'll be uploading my work to some git repo within the next days. If
you guys consider it too much to use a new libpthread, then we can always
cherrypick what it's best and incorporate it to what the Hurd currently has.
