Mutexes and error checking

[Koop Mast]

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
>>
>