Date: Thu, 9 Sep 2004 11:37:06 -0400 From: Coleman Kane <zombyfork@gmail.com> To: Brian Fundakowski Feldman <green@freebsd.org> Cc: Pascal Hofstee <caelian@gmail.com> Subject: Re: pthread_mutex_trylock and glib-2 Message-ID: <346a8022040909083715251d8f@mail.gmail.com> In-Reply-To: <20040908225709.GI928@green.homeunix.org> References: <d8a0b76204090615122c68fa3e@mail.gmail.com> <d8a0b76204090718275d0269c5@mail.gmail.com> <20040908225709.GI928@green.homeunix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <green@freebsd.org> 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 <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. > > 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 ]''''''''''\ > <> green@FreeBSD.org \ The Power to Serve! \ > Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?346a8022040909083715251d8f>