Date: Wed, 09 May 2001 19:20:07 +0900 From: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> 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 Message-ID: <200105091020.f49AK7P05497@rina.r.dl.itc.u-tokyo.ac.jp> In-Reply-To: In your message of "Tue, 08 May 2001 08:21:55 -0700 (PDT)" <XFMail.010508082155.jhb@FreeBSD.org> References: <200105081026.f48AQgP75260@rina.r.dl.itc.u-tokyo.ac.jp> <XFMail.010508082155.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 08 May 2001 08:21:55 -0700 (PDT), John Baldwin <jhb@FreeBSD.org> 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 <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?200105091020.f49AK7P05497>