From owner-freebsd-threads@FreeBSD.ORG  Tue Jul 23 16:45:18 2013
Return-Path: <owner-freebsd-threads@FreeBSD.ORG>
Delivered-To: freebsd-threads@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 by hub.freebsd.org (Postfix) with ESMTP id 10CA5F58;
 Tue, 23 Jul 2013 16:45:18 +0000 (UTC)
 (envelope-from deischen@freebsd.org)
Received: from mail.netplex.net (mail.netplex.net [204.213.176.9])
 (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mx1.freebsd.org (Postfix) with ESMTPS id C668E2948;
 Tue, 23 Jul 2013 16:45:17 +0000 (UTC)
Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11])
 by mail.netplex.net (8.14.6/8.14.6/NETPLEX) with ESMTP id r6NGjFr5011890;
 Tue, 23 Jul 2013 12:45:15 -0400
X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net)
X-Greylist: Message whitelisted by DRAC access database, not delayed by
 milter-greylist-4.4.1 (mail.netplex.net [204.213.176.9]);
 Tue, 23 Jul 2013 12:45:16 -0400 (EDT)
Date: Tue, 23 Jul 2013 12:45:15 -0400 (EDT)
From: Daniel Eischen <deischen@freebsd.org>
X-X-Sender: eischen@sea.ntplx.net
To: Joe Marcus Clarke <marcus@marcuscom.com>
Subject: Re: Mutexes and error checking
In-Reply-To: <51EEACC9.8000406@marcuscom.com>
Message-ID: <Pine.GSO.4.64.1307231236440.15999@sea.ntplx.net>
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>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: kwm@rainbow-runner.nl, avg@freebsd.org, freebsd-threads@freebsd.org
X-BeenThere: freebsd-threads@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
Reply-To: Daniel Eischen <deischen@freebsd.org>
List-Id: Threading on FreeBSD <freebsd-threads.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-threads>, 
 <mailto:freebsd-threads-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-threads>
List-Post: <mailto:freebsd-threads@freebsd.org>
List-Help: <mailto:freebsd-threads-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-threads>,
 <mailto:freebsd-threads-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jul 2013 16:45:18 -0000

On Tue, 23 Jul 2013, 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.

FYI, here is a very lighty tested patch that allows an unlock on
a PTHREAD_MUTEX_NORMAL mutex by a non-owning thread:

   http://people.freebsd.org/~deischen/libthr_mutex_normal.diffs

I do not argue for or against this behavior in making this patch,
as I can see both sides of the argument.

-- 
DE