From owner-svn-src-head@FreeBSD.ORG Wed Mar 5 23:35:06 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31710A95; Wed, 5 Mar 2014 23:35:06 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AACF1D49; Wed, 5 Mar 2014 23:35:04 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.8/8.14.8) with ESMTP id s25NYo9c071957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Mar 2014 03:34:50 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.8/8.14.8/Submit) id s25NYoPd071956; Thu, 6 Mar 2014 03:34:50 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 6 Mar 2014 03:34:50 +0400 From: Gleb Smirnoff To: Adrian Chadd Subject: Re: svn commit: r262806 - head/sys/net Message-ID: <20140305233450.GG68791@FreeBSD.org> References: <201403052116.s25LGkEq007924@svn.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Cc: "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , "src-committers@freebsd.org" X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 23:35:06 -0000 On Wed, Mar 05, 2014 at 03:29:55PM -0800, Adrian Chadd wrote: A> ... why's the code returning locked mutexes to UMA? A> A> Why not fix the places that are doing this and doing a lock assertion A> in the destructor? What's this buy us? A> A> I'm very wary of design patterns like this that do conditional A> unlocking in free/destructor routines; it allows for the caller to not A> necessarily get all the lock/unlock stuff to line up in the main code A> and it can make debugging more of a pain. I get your point, and even share it. I discussed that with melifaro@, he prefers destructors being smart. Note that mutex(9) by design allows to destroy a locked mutex. And route(4) relied on this semantics. Now I converted route(4) to lazy mutex deallocation. Of course, if mutex(9) didn't allow such trick, I wouldn't implement the code I did. But since code of route(4) was not considered broken before, I decided to keep status quo. -- Totus tuus, Glebius.