From owner-freebsd-hackers@FreeBSD.ORG Wed May 2 16:53:03 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 216D416A408 for ; Wed, 2 May 2007 16:53:03 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outM.internet-mail-service.net (outM.internet-mail-service.net [216.240.47.236]) by mx1.freebsd.org (Postfix) with ESMTP id E8C8C13C455 for ; Wed, 2 May 2007 16:53:02 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Wed, 02 May 2007 09:19:26 -0700 Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 3CAD1125B37; Wed, 2 May 2007 09:53:02 -0700 (PDT) Message-ID: <4638C1ED.5020607@elischer.org> Date: Wed, 02 May 2007 09:53:01 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: attilio@FreeBSD.org References: <200704262136.33196.hselasky@c2i.net> <200704270748.49404.hselasky@c2i.net> <200704271917.29939.hselasky@freebsd.org> <46323A77.8010907@elischer.org> <4638BF32.5040607@FreeBSD.org> In-Reply-To: <4638BF32.5040607@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , freebsd-hackers@freebsd.org, Hans Petter Selasky Subject: Re: msleep() on recursivly locked mutexes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2007 16:53:03 -0000 Attilio Rao wrote: > Julian Elischer wrote: >> Hans Petter Selasky wrote: >> >>> First of all: Where is FreeBSD's locking strategy document? >> It is just started.. man 9 locking. it needs a lot of work still. > > I'm working with rwatson@ about a document that can nicely fit in > locking(9), but we are a little bit stuck in terminology. > In order to not confuse even more locking consumers we are trying to > find right and unique terms for kernel events linked to locks. > > > Attilio send me what you have :-) I'll look at it too.