pthread_mutex_trylock and glib-2
Pascal Hofstee
caelian at gmail.com
Mon Sep 6 15:12:18 PDT 2004
After a few hours of digging through both the glib-2 as well as the
beep-media-player sources i finally managed to figure out why
beep-media-player apprently crashes on startup when using libpthread,
but not when using libc_r.
i filed a bugreport against this problem on bugzilla.gnome.org ... in
the hope to get some feedback from glib-developers ...
http://bugzilla.gnome.org/show_bug.cgi?id=152009
The problem is with the actual return value of pthread_mutex_trylock
returning EDEADLK instead of EBUSY.
from what i have been able to glance from this previous discussion
regarding this particular subject
(http://lists.freebsd.org/pipermail/freebsd-threads/2004-January/001539.html)
pthread_mutex_trylock should behave identical to pthread_mutex_lock
except return immediately in case of a blocking mutex, which would
suggest EDEADLK as a possible return value.
This Seems to be the current implementation of both libpthread as well
as libthr ... with libc_r being the sole exception.
The pthread_mutex_trylock manpage however does not reflect this actual
implementation and only mentions EBUSY and EINVAL.
I was wondering assuming the implementation is actually correct if
this could be rectified in the pthread_mutex_trylock manpage ... and
if my assumption is wrong if the implementation could be changed to
reflect the manpage.
In the former case i will have to bug the glib-devs to change the
implementation of their pthread_mutex_trylock wrapper ... to also
check for EDEADLK.
--
With kind regards,
Pascal Hofstee
More information about the freebsd-hackers
mailing list