Date: Thu, 10 May 2001 09:06:15 +0900 From: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> To: John Baldwin <jhb@FreeBSD.org> Cc: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>, current@FreeBSD.org Subject: Re: select(2) converted to use a condition variable, and optimis Message-ID: <200105100006.f4A06Gj35470@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> In-Reply-To: <XFMail.010509092109.jhb@FreeBSD.org> References: <200105091020.f49AK7P05497@rina.r.dl.itc.u-tokyo.ac.jp> <XFMail.010509092109.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 09 May 2001 09:21:09 -0700 (PDT), John Baldwin <jhb@FreeBSD.org> 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 <tanimura@r.dl.itc.u-tokyo.ac.jp> <tanimura@FreeBSD.org> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200105100006.f4A06Gj35470>