Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 7 Sep 2004 18:27:14 -0700
From:      Pascal Hofstee <caelian@gmail.com>
To:        freebsd-hackers@freebsd.org
Cc:        gnome@FreeBSD.org
Subject:   Re: pthread_mutex_trylock and glib-2
Message-ID:  <d8a0b76204090718275d0269c5@mail.gmail.com>
In-Reply-To: <d8a0b76204090615122c68fa3e@mail.gmail.com>
References:  <d8a0b76204090615122c68fa3e@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
------=_Part_171_15976079.1094606834411
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Mon, 6 Sep 2004 15:12:08 -0700, Pascal Hofstee <caelian@gmail.com> wrote:
> 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.

I am hereby including an updated
/usr/ports/devel/glib20/files/patch-gthread_gthread-posix.c

that includes the additional check for EDEADLK besides EBUSY in glib's
g_mutex_trylock_posix_impl function.

With this fix applied to my installation of glib beep-media-player now
works as expected with libpthread, and this is very likely to resolve
similar behaviour with other ports that try to use glib's threading
functions.

I CC-ed glib20 port-maintainer (gnome@FreeBSD.org) in the hope this
(or appropriate alternative) fix makes it in time for 5.3-RELEASE.

-- 
  Pascal Hofstee

------=_Part_171_15976079.1094606834411
Content-Type: application/octet-stream; name="patch-gthread_gthread-posix.c"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="patch-gthread_gthread-posix.c"

LS0tIGd0aHJlYWQvZ3RocmVhZC1wb3NpeC5jLm9yaWcJVHVlIFNlcCAgNyAxNzo1Nzo1MyAyMDA0
CisrKyBndGhyZWFkL2d0aHJlYWQtcG9zaXguYwlUdWUgU2VwICA3IDE3OjU4OjMwIDIwMDQKQEAg
LTExNiw2ICsxMTYsNyBAQAogI2VuZGlmIC8qIFBPU0lYX01JTl9QUklPUklUWSAmJiBQT1NJWF9N
QVhfUFJJT1JJVFkgKi8KIAogc3RhdGljIGd1bG9uZyBnX3RocmVhZF9taW5fc3RhY2tfc2l6ZSA9
IDA7CitzdGF0aWMgZ3Vsb25nIGdfdGhyZWFkX2RlZmF1bHRfc3RhY2tfc2l6ZSA9IDB4MTAwMDAw
OwogCiAjZGVmaW5lIEdfTVVURVhfU0laRSAoc2l6ZW9mIChwdGhyZWFkX211dGV4X3QpKQogCkBA
IC0xMjUsNyArMTI2LDggQEAKIGdfdGhyZWFkX2ltcGxfaW5pdCgpCiB7CiAjaWZkZWYgX1NDX1RI
UkVBRF9TVEFDS19NSU4KLSAgZ190aHJlYWRfbWluX3N0YWNrX3NpemUgPSBNQVggKHN5c2NvbmYg
KF9TQ19USFJFQURfU1RBQ0tfTUlOKSwgMCk7CisgIGdfdGhyZWFkX21pbl9zdGFja19zaXplID0g
TUFYIChzeXNjb25mIChfU0NfVEhSRUFEX1NUQUNLX01JTiksCisgICAgZ190aHJlYWRfbWluX3N0
YWNrX3NpemUpOwogI2VuZGlmIC8qIF9TQ19USFJFQURfU1RBQ0tfTUlOICovCiAjaWZkZWYgSEFW
RV9QUklPUklUSUVTCiAjIGlmZGVmIEdfVEhSRUFEU19JTVBMX1BPU0lYCkBAIC0xNzYsNyArMTc4
LDcgQEAKICAgcmVzdWx0ID0gcHRocmVhZF9tdXRleF90cnlsb2NrICgocHRocmVhZF9tdXRleF90
ICopIG11dGV4KTsKIAogI2lmZGVmIEdfVEhSRUFEU19JTVBMX1BPU0lYCi0gIGlmIChyZXN1bHQg
PT0gRUJVU1kpCisgIGlmICgocmVzdWx0ID09IEVCVVNZKSB8fCAocmVzdWx0ID09IEVERUFETEsp
KQogICAgIHJldHVybiBGQUxTRTsKICNlbHNlIC8qIEdfVEhSRUFEU19JTVBMX0RDRSAqLwogICBp
ZiAocmVzdWx0ID09IDApCkBAIC0zMDcsOCArMzA5LDEyIEBACiAgIGlmIChzdGFja19zaXplKQog
ICAgIHsKICAgICAgIHN0YWNrX3NpemUgPSBNQVggKGdfdGhyZWFkX21pbl9zdGFja19zaXplLCBz
dGFja19zaXplKTsKLSAgICAgIHBvc2l4X2NoZWNrX2NtZCAocHRocmVhZF9hdHRyX3NldHN0YWNr
c2l6ZSAoJmF0dHIsIHN0YWNrX3NpemUpKTsKICAgICB9CisgIGVsc2UKKyAgICB7CisgICAgICBz
dGFja19zaXplID0gTUFYIChnX3RocmVhZF9taW5fc3RhY2tfc2l6ZSwgZ190aHJlYWRfZGVmYXVs
dF9zdGFja19zaXplKTsKKyAgICB9CisgIHBvc2l4X2NoZWNrX2NtZCAocHRocmVhZF9hdHRyX3Nl
dHN0YWNrc2l6ZSAoJmF0dHIsIHN0YWNrX3NpemUpKTsKICNlbmRpZiAvKiBIQVZFX1BUSFJFQURf
QVRUUl9TRVRTVEFDS1NJWkUgKi8KIAogI2lmZGVmIFBUSFJFQURfU0NPUEVfU1lTVEVNCg==
------=_Part_171_15976079.1094606834411--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d8a0b76204090718275d0269c5>