Date: Thu, 10 May 2001 08:39:53 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> Cc: John Baldwin <jhb@FreeBSD.ORG>, current@FreeBSD.ORG Subject: Re: select(2) converted to use a condition variable, and optimis Message-ID: <3AFAB649.67D53F11@mindspring.com> References: <200105091020.f49AK7P05497@rina.r.dl.itc.u-tokyo.ac.jp> <XFMail.010509092109.jhb@FreeBSD.org> <200105100006.f4A06Gj35470@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
Seigo Tanimura wrote: > 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). Let me once again point out that fhold(), like crhold(), should act as an l-valued function that takes an r-value as an "argument", as in: a = crhold(b); q = fhold(r); etc. (for all such functions). The reason is that you can not replace it with an instrumented function, otherwise, which would permit you to catch subtle errors that: a = b; crhold(a); q = r; fhold(r); etc. may cause (yes, I know I have held the r-calue in one case and the l-value in the other in the above example; the kernel itself does this all over the place, and I think it's an error). I also think that they should use common base macros: it is exceedingly dangerous to have multiple hold semantics in the kernel. -- Terry 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?3AFAB649.67D53F11>