Re: pthread_mutex_trylock and glib-2
Yeah, I had the same problem. Fixed it by not building with debug code, but I noticed there was chatter about it. On Wed, 8 Sep 2004 18:57:09 -0400, Brian Fundakowski Feldman [EMAIL PROTECTED] wrote: On Tue, Sep 07, 2004 at 06:27:14PM -0700, Pascal Hofstee wrote: On Mon, 6 Sep 2004 15:12:08 -0700, Pascal Hofstee [EMAIL PROTECTED] 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 ([EMAIL PROTECTED]) in the hope this (or appropriate alternative) fix makes it in time for 5.3-RELEASE. FWIW, I had to fix a similar problem in mozilla/NSPR's codebase to make the build with debugging code turned on work. Well, I guess it was really the same problem. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pthread_mutex_trylock and glib-2
Ok .. Got some bugzilla notifications ...and apparently this issue has been targetted for glib-2.4.7 with keywords portability. So i assume we'll most likely have to include my provided patch for the glib20 port until 2.4.7 comes out and an appropriate fix will probably have been included by then. -- Pascal Hofstee ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pthread_mutex_trylock and glib-2
On Tue, Sep 07, 2004 at 06:27:14PM -0700, Pascal Hofstee wrote: On Mon, 6 Sep 2004 15:12:08 -0700, Pascal Hofstee [EMAIL PROTECTED] 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 ([EMAIL PROTECTED]) in the hope this (or appropriate alternative) fix makes it in time for 5.3-RELEASE. FWIW, I had to fix a similar problem in mozilla/NSPR's codebase to make the build with debugging code turned on work. Well, I guess it was really the same problem. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pthread_mutex_trylock and glib-2
On Mon, 6 Sep 2004 15:12:08 -0700, Pascal Hofstee [EMAIL PROTECTED] 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 ([EMAIL PROTECTED]) in the hope this (or appropriate alternative) fix makes it in time for 5.3-RELEASE. -- Pascal Hofstee patch-gthread_gthread-posix.c Description: Binary data ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
pthread_mutex_trylock and glib-2
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 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pthread_mutex_trylock and glib-2
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. 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. Well, according to http://www.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_trylock.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. The pthread_mutex_lock() function may fail if: [EDEADLK] A deadlock condition was detected or the current thread already owns the mutex. %%% 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 -- I wish there was a knob on the TV to turn up the intelligence. There's a knob called `brightness', but it doesn't work. -- Gallagher pgpXsqnDvDflW.pgp Description: PGP signature
