From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 6 22:12:18 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B6F916A4CE for ; Mon, 6 Sep 2004 22:12:18 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18E4443D41 for ; Mon, 6 Sep 2004 22:12:18 +0000 (GMT) (envelope-from caelian@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so146532rnl for ; Mon, 06 Sep 2004 15:12:08 -0700 (PDT) Received: by 10.38.82.8 with SMTP id f8mr1622011rnb; Mon, 06 Sep 2004 15:12:08 -0700 (PDT) Received: by 10.38.79.10 with HTTP; Mon, 6 Sep 2004 15:12:08 -0700 (PDT) Message-ID: Date: Mon, 6 Sep 2004 15:12:08 -0700 From: Pascal Hofstee To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: pthread_mutex_trylock and glib-2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Pascal Hofstee List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2004 22:12:18 -0000 After a few hours of digging through both the glib-2 as well as the beep-media-player sources i finally managed to figure out why beep-media-player apprently crashes on startup when using libpthread, but not when using libc_r. i filed a bugreport against this problem on bugzilla.gnome.org ... in the hope to get some feedback from glib-developers ... http://bugzilla.gnome.org/show_bug.cgi?id=152009 The problem is with the actual return value of pthread_mutex_trylock returning EDEADLK instead of EBUSY. from what i have been able to glance from this previous discussion regarding this particular subject (http://lists.freebsd.org/pipermail/freebsd-threads/2004-January/001539.html) pthread_mutex_trylock should behave identical to pthread_mutex_lock except return immediately in case of a blocking mutex, which would suggest EDEADLK as a possible return value. This Seems to be the current implementation of both libpthread as well as libthr ... with libc_r being the sole exception. The pthread_mutex_trylock manpage however does not reflect this actual implementation and only mentions EBUSY and EINVAL. I was wondering assuming the implementation is actually correct if this could be rectified in the pthread_mutex_trylock manpage ... and if my assumption is wrong if the implementation could be changed to reflect the manpage. In the former case i will have to bug the glib-devs to change the implementation of their pthread_mutex_trylock wrapper ... to also check for EDEADLK. -- With kind regards, Pascal Hofstee