From owner-freebsd-current@FreeBSD.ORG Wed Nov 30 16:20:07 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 308A6106564A; Wed, 30 Nov 2011 16:20:07 +0000 (UTC) (envelope-from mlfbsd@kanar.ci0.org) Received: from kanar.ci0.org (unknown [IPv6:2a01:e0b:1:50:40:63ff:feea:93a]) by mx1.freebsd.org (Postfix) with ESMTP id B5FDC8FC14; Wed, 30 Nov 2011 16:20:06 +0000 (UTC) Received: from kanar.ci0.org (pluxor@localhost [127.0.0.1]) by kanar.ci0.org (8.14.2/8.14.3) with ESMTP id pAUGKH95053575; Wed, 30 Nov 2011 17:20:17 +0100 (CET) (envelope-from mlfbsd@kanar.ci0.org) Received: (from mlfbsd@localhost) by kanar.ci0.org (8.14.2/8.14.3/Submit) id pAUGKH0R053574; Wed, 30 Nov 2011 17:20:17 +0100 (CET) (envelope-from mlfbsd) Date: Wed, 30 Nov 2011 17:20:17 +0100 From: Olivier Houchard To: Kostik Belousov Message-ID: <20111130162017.GA53362@ci0.org> References: <20111130124320.GA1449@azathoth.lan> <201111301005.11938.jhb@freebsd.org> <20111130154636.GX50300@deviant.kiev.zoral.com.ua> <20111130155521.GA52567@ci0.org> <20111130160450.GY50300@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111130160450.GY50300@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Wed, 30 Nov 2011 16:51:06 +0000 Cc: Baptiste Daroussin , freebsd-current@freebsd.org, Olivier Houchard Subject: Re: [patch] turning devctl into a "multiple openable" device X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 16:20:07 -0000 On Wed, Nov 30, 2011 at 06:04:50PM +0200, Kostik Belousov wrote: > > > I wonder why the waiting_threads stuff is needed at all. The cv could > > > be woken up unconditionally everytime. What is the reason for the cv_wait > > > call in cdevpriv data destructor ? You cannot have a thread doing e.g. > > > read on the file descriptor while destructor is run. > > > > > > > What will prevent you from having a thread stuck in read(), while an another > > one close() the fd ? > > > Nothing, but file reference count goes to zero only after the thread > stuck in read is unstuck. Cdevpriv destructor is run only when file > reference count becomes zero, i.e. there can be no any accessing threads, > and new accesses are impossible since file descriptors also own references > on the file. Right, I was a bit confused, this part can be removed. Regards, Olivier