Date: Wed, 24 Jul 2013 12:53:28 +0200 From: Koop Mast <kwm@rainbow-runner.nl> To: Joe Marcus Clarke <marcus@marcuscom.com> Cc: deischen@freebsd.org, avg@freebsd.org, freebsd-threads@freebsd.org Subject: Re: Mutexes and error checking Message-ID: <51EFB228.20907@rainbow-runner.nl> In-Reply-To: <51EEACC9.8000406@marcuscom.com> References: <51E71D4F.5030502@marcuscom.com> <Pine.GSO.4.64.1307181059460.22570@sea.ntplx.net> <51E8061B.60906@marcuscom.com> <Pine.GSO.4.64.1307181118100.22570@sea.ntplx.net> <Pine.GSO.4.64.1307182144030.23634@sea.ntplx.net> <Pine.GSO.4.64.1307190152440.25756@sea.ntplx.net> <51EB5EC4.6050802@marcuscom.com> <20130721160220.GA38417@stack.nl> <51EC0BCF.6080501@FreeBSD.org> <51EC49F8.6070207@marcuscom.com> <201307231543.r6NFhS7n007384@higson.cam.lispworks.com> <51EEACC9.8000406@marcuscom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 07/23/13 18:18, Joe Marcus Clarke wrote: > On 7/23/13 11:43 AM, Martin Simmons wrote: >>>>>>> On Sun, 21 Jul 2013 16:52:08 -0400, Joe Marcus Clarke said: >>> The specifics are this. There are some GNOME/GTK+/GLib apps that are >>> crashing now that GLib checks the return of pthread_mutex_unlock() in >>> g_mutex_unlock(). While we can workaround this in GLib by simply >>> nop'ing the EPERM return, we'd like to pursue something that may be a >>> bit more manageable for those apps written for Linux that do not use GLib. >> Which apps are broken and why can't they be fixed? > Koop, do you have a complete list? The one that was reported to me was > sonata (a Python app). I have not yet traced down the offending code as > I was curious why Linux was not failing, and this appears to be why. > > Joe I only am aware of audio/sonata currently. I can remember seeing a similar error once or twice before. So while looking for more failures like the one in sonata, I ran into a fix for sonata in the OpenBSD ports [1]. . I also found the same solution was fixed in lxpanel [2]. The fix is to use the |GDK| mutual exclusion lock to prevent more then one thread being active [3]. With this I can fix the few ports that exhibit this problem and we don't have to change anything in base. -Koop [1] http://www.openbsd.org/cgi-bin/cvsweb/ports/audio/sonata/patches/patch-sonata_main_py?rev=1.5;content-type=text%2Fplain [2] https://github.com/hsgg/lxpanel/commit/75f5e575e692818869cb3d7fded6f42c735f6954 [3] http://www.pygtk.org/docs/pygtk/gdk-functions.html#function-gdk--threads-enter >> >>> Again, I'm not arguing the voracity of the 3rd party app code, just the >>> discrepancy between Linux and Solaris compared to FreeBSD. >> Note that unlocking an unlocked normal mutex on Linux (glibc) does *not* work, >> but leaves it in a subtly inconsistent state. Therefore bugs like the one you >> reported to the GNOME Bugzilla >> (https://bugzilla.gnome.org/show_bug.cgi?id=678758) should be fixed, not >> ignored by hiding the error status. >> >> __Martin >> >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51EFB228.20907>