* Pekka Enberg <[email protected]> wrote:
> The pthread_mutex_{lock|unlock} functions return non-zero, not negative number
> upon error. Fix that wrong assumption in the code.
glibc/pthreads mutex API semantics are pretty silly IMO.
I *think* it would be better to try to match the kernel API here, and provide
trivial wrappers around mutex_lock()/mutex_unlock(). We wont ever bring down
threads in a hostile way, so we wont actually need the error returns. CPU
threads should probably only exit once the kvm process exits, after all cleanup
has been done.
So mutex_lock() could be implemented as something like:
void mutex_lock(pthread_mutex_t mutex)
{
if (pthread_mutex_lock(mutex) != 0)
die("unexpected pthread_mutex_lock() failure!");
}
That way usage would be more obvious and more familar to kernel developers :-)
[ It would also open up the possibility, in the far future, to bring lockdep to
user-space ;-) ]
What do you think?
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
