Date: Sun, 27 Feb 2005 11:05:19 +0000 From: David Malone <dwmalone@maths.tcd.ie> To: Yan Yu <yanyu@CS.UCLA.EDU> Cc: freebsd-hackers@freebsd.org Subject: Re: function prototype of fdrop() and fdrop_locked() in kern_descrip.c Message-ID: <20050227110519.GA23630@walton.maths.tcd.ie> In-Reply-To: <Pine.GSO.4.58.0502262309170.29499@panther.cs.ucla.edu> References: <20050226072645.76950.qmail@web26802.mail.ukl.yahoo.com> <Pine.GSO.4.58.0502260043200.12442@panther.cs.ucla.edu> <Pine.GSO.4.58.0502260103420.13229@panther.cs.ucla.edu> <Pine.GSO.4.58.0502260111400.13229@panther.cs.ucla.edu> <Pine.GSO.4.58.0502262309170.29499@panther.cs.ucla.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Feb 26, 2005 at 11:22:03PM -0800, Yan Yu wrote: > I am wondering about what is the motivation of fdrop is defined as > A) as opposed to B).. or it is an arbitrary design choice? > it seems to me fdrop is called usually when an fd is freed(or is there > other reason that fdrop get called?), fdrop is called to drop the reference count in a file structure. That file structure may or may not correspond to a file that has an entry in the file discriptor table. For example, suppose you have two processes sharing a file discriptor table (as happens with certain threading schemes) and the following happens: thread 1 thread 2 calls read on fd 1 *sleeps in read* closes fd 1 read completes At the time read completes, there is no entry in any file discriptor table for fd 1, but read is still using the file structure, so it must remain valid even though the file has been closed. Similar things can happen while descriptors are being passed over Unix domain sockets. So, fdrop is to do with the lifetime of the file structure not the lifetime of the file discriptor entry. If you want to track file discriptor entries, you'll have to track where fd_ofiles is manuipulated - these should be fairly obvious as they all involve grabbing the FILEDESC_LOCK. David.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050227110519.GA23630>