Skip site navigation (1)Skip section navigation (2)
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: <http://docs.FreeBSD.org/cgi/mid.cgi?51EFB228.20907>