Date: Wed, 09 May 2001 09:21:09 -0700 (PDT) From: John Baldwin <jhb@FreeBSD.org> To: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> Cc: current@FreeBSD.org Subject: RE: select(2) converted to use a condition variable, and optimis Message-ID: <XFMail.010509092109.jhb@FreeBSD.org> In-Reply-To: <200105091020.f49AK7P05497@rina.r.dl.itc.u-tokyo.ac.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
On 09-May-01 Seigo Tanimura wrote: > 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. > > 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. Free'ing is not all that problematic since it doesn't sleep. It is more problematic atm because it can result in lock order reversals due to lockmgr 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. Argh, ok. Eventually this issue may go away as well. > 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. Ok, sounds good. Just wanted to make sure. -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.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?XFMail.010509092109.jhb>