Date: Sun, 21 Jul 2013 16:52:08 -0400 From: Joe Marcus Clarke <marcus@marcuscom.com> To: Andriy Gapon <avg@FreeBSD.org> Cc: Daniel Eischen <deischen@FreeBSD.org>, Koop Mast <kwm@rainbow-runner.nl>, freebsd-threads@FreeBSD.org Subject: Re: Mutexes and error checking Message-ID: <51EC49F8.6070207@marcuscom.com> In-Reply-To: <51EC0BCF.6080501@FreeBSD.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7/21/13 12:26 PM, Andriy Gapon wrote: > on 21/07/2013 19:02 Jilles Tjoelker said the following: >> So I think allowing pthread_mutex_unlock() by a different thread would >> be a step backwards. > > There is something else that bothers me too. > Properly written code always "knows" whether it has a lock or not. It does not > try to unlock on a whim. Apparently the software in question is not properly > written. Nevertheless, it takes care to check return status of > pthread_mutex_unlock(). And, to add insult to injury, it depends on OS-specific > behavior in doing so. That seems like "two wrongs make a right" thing. 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. Again, I'm not arguing the voracity of the 3rd party app code, just the discrepancy between Linux and Solaris compared to FreeBSD. Joe -- PGP Key : http://www.marcuscom.com/pgp.asc
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51EC49F8.6070207>