Date: Tue, 7 Sep 2004 06:58:09 +0200 From: Stijn Hoop <stijn@win.tue.nl> To: Pascal Hofstee <caelian@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: pthread_mutex_trylock and glib-2 Message-ID: <20040907045809.GB10111@pcwin002.win.tue.nl> In-Reply-To: <d8a0b76204090615122c68fa3e@mail.gmail.com> References: <d8a0b76204090615122c68fa3e@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--pvezYHf7grwyp3Bc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, thanks for digging at this! On Mon, Sep 06, 2004 at 03:12:08PM -0700, Pascal Hofstee 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. >=20 > i filed a bugreport against this problem on bugzilla.gnome.org ... in > the hope to get some feedback from glib-developers ... >=20 > http://bugzilla.gnome.org/show_bug.cgi?id=3D152009 >=20 > The problem is with the actual return value of pthread_mutex_trylock > returning EDEADLK instead of EBUSY. >=20 > 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.h= tml) >=20 > 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. Well, according to http://www.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_trylo= ck.html (linked from the discussion above), I would read this: %%% The pthread_mutex_trylock() function shall fail if: [EBUSY] The mutex could not be acquired because it was already locked.=20 The pthread_mutex_lock() function may fail if: [EDEADLK] A deadlock condition was detected or the current thread already owns th= e mutex.=20 %%% as the glib developers apparently did -- namely that pthread_mutex_trylock cannot return EDEADLK, only EBUSY. The fact that it is the current thread that has already locked the mutex is only required to be detected by the pthread_mutex_lock function. In other words, I agree with Mike Makonnen in your quoted e-mail, but apparently the implementation does not. In any case, modifying glib to also check for EDEADLK would probably be appropriate. --Stijn --=20 I wish there was a knob on the TV to turn up the intelligence. There's a k= nob called `brightness', but it doesn't work." -- Gallagher --pvezYHf7grwyp3Bc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBPT/gY3r/tLQmfWcRAi2qAJwNTIPa4eiOzG5wBbxgXsBUKqiV+wCfVOuQ 7s7cSOgMe1ic28Q3j5XaoK0= =3mdA -----END PGP SIGNATURE----- --pvezYHf7grwyp3Bc--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040907045809.GB10111>