From owner-freebsd-current Wed May 9 6:40:48 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 AF83137B423; Wed, 9 May 2001 06:40:39 -0700 (PDT) (envelope-from tanimura@r.dl.itc.u-tokyo.ac.jp) Received: from rina.r.dl.itc.u-tokyo.ac.jp (localhost [127.0.0.1]) by rina.r.dl.itc.u-tokyo.ac.jp (8.11.3+3.4W/3.7W-rina.r-20010412) with ESMTP id f49AK7P05497 ; Wed, 9 May 2001 19:20:08 +0900 (JST) Message-Id: <200105091020.f49AK7P05497@rina.r.dl.itc.u-tokyo.ac.jp> Date: Wed, 09 May 2001 19:20:07 +0900 From: Seigo Tanimura To: jhb@FreeBSD.org Cc: tanimura@r.dl.itc.u-tokyo.ac.jp, current@FreeBSD.org Subject: RE: select(2) converted to use a condition variable, and optimis In-Reply-To: In your message of "Tue, 08 May 2001 08:21:55 -0700 (PDT)" References: <200105081026.f48AQgP75260@rina.r.dl.itc.u-tokyo.ac.jp> User-Agent: Wanderlust/1.1.1 (Purple Rain) 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 Tue, 08 May 2001 08:21:55 -0700 (PDT), John Baldwin said: John> On 08-May-01 Seigo Tanimura wrote: >> Here is another issue. PROC_LOCK may block to acquire a process lock, >> during which an event of interest may occur or the remaining time of >> select(2)/poll(2) may run out. Thus if the remaining time runs out >> during locking a process, we should first rescan file descriptors to >> avoid missing an event, followed by returning the result. John> Hmmm. Actually, can the nb_poll, ncp_poll, pollscan, or selscan functions call John> tsleep/msleep? If they don't, then we are just better off holding proc lock John> while we call them rather than releasing it just to call that function and John> acquiring it later. Then we don't have to work around the race you describe. Poling functions called via fo_poll in a file descriptor should not call msleep(9) in theory. That does not, however, necessarily imply that we can scan file descriptors with holding a process lock. Another process can release a reference to a file descriptor via closef() during polling the descriptor by calling its fo_poll. In this case, fdrop() subsequent to the call of fo_poll may result the reference count of the descriptor to be zero. 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. 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> Also, in the done_noproclock: case (might want to use 'unlock:' and 'done:' John> instead of 'done:' and 'done_noproclock:' for label names instead) are you John> always sure that when you go to that label you don't need to clear P_SELECT? select(2) and poll(2) set P_SELECT below retry: and clear P_SELECT upon occurrence of an event or timeout. There are no other places than them for a process to set P_SELECT in its p_flag. Thus we can assume at the entry of select(2) and poll(2) that P_SELECT is not set. We go to done_noproclock if and only if either copyin() or sanity check of arguments fails. As we do not poll any descriptors in this case, it is not necessary to clear P_SELECT. -- Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message