From owner-freebsd-current Wed May 9 17: 7:17 2001 Delivered-To: freebsd-current@freebsd.org Received: from rina.r.dl.itc.u-tokyo.ac.jp (cvsup2.r.dl.itc.u-tokyo.ac.jp [133.11.199.247]) by hub.freebsd.org (Postfix) with ESMTP id 364F137B422; Wed, 9 May 2001 17:07:14 -0700 (PDT) (envelope-from tanimura@r.dl.itc.u-tokyo.ac.jp) Received: (from uucp@localhost) by rina.r.dl.itc.u-tokyo.ac.jp (8.11.3+3.4W/3.7W-rina.r-20010412) with UUCP id f4A07DE14626 ; Thu, 10 May 2001 09:07:13 +0900 (JST) Received: from silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp (silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp [fec0::1:280:c8ff:fe6b:6d73]) by sohgo.carrots.uucp.r.dl.itc.u-tokyo.ac.jp (8.11.3+3.4W/3.7W) with ESMTP id f4A06LJ25747 ; Thu, 10 May 2001 09:06:21 +0900 (JST) Received: from silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp (localhost [127.0.0.1]) by silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp (8.11.3+3.4W/3.7W) with ESMTP id f4A06Gj35470 ; Thu, 10 May 2001 09:06:18 +0900 (JST) Message-Id: <200105100006.f4A06Gj35470@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> Date: Thu, 10 May 2001 09:06:15 +0900 From: Seigo Tanimura To: John Baldwin Cc: Seigo Tanimura , current@FreeBSD.org Subject: Re: select(2) converted to use a condition variable, and optimis In-Reply-To: References: <200105091020.f49AK7P05497@rina.r.dl.itc.u-tokyo.ac.jp> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Digital Library Research Division, Information Techinology Centre, The University of Tokyo MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 09 May 2001 09:21:09 -0700 (PDT), John Baldwin said: >> Now the problem is whether it is easy or difficult to free a file >> descriptor with holding a process lock. At the level of the file >> descriptor layer, we can convert the memory allocator of a file >> descriptor from malloc(9) to the zone allocator, which locks only the >> zone state for file descriptors by a mutex. John> Free'ing is not all that problematic since it doesn't sleep. It is more John> problematic atm because it can result in lock order reversals due to lockmgr John> headaches. Eventually this won't become an issue I hope. >> It is a crucial issue to release an object underlying a file >> descriptor. Releasing a vnode can result in calling msleep(9) for >> locking the vnode in vrele(). Releasing a socket may end up with >> calling tsleep(9) for draining data if SO_LINGER is set. Hence we >> cannot scan file descriptors with holding a process lock for now. John> Argh, ok. Eventually this issue may go away as well. A quick and hopefully efficient solution to those problems is to fhold() struct file's first, then enter polling loop. That seems much cheaper than to work on free()ing a vnode or a socket with holding a process lock, provided that struct filedesc and file are protected properly (and we have to do it anyway). -- Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message