site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... At 14:51 +0530 21/1/09, Narayan Subramanian wrote: My question here is: Do we not call close() on the executable files descriptor after we mmap() them into the process address space (inside dyld)? I am assuming that the vnode corresponding to the file descriptor should get freed after the file descriptor gets closed (right?). (I mean isn't that the only way we can move around an (on disk) executable file that being run by another process?). If that is true, how is it that we are still able to trace the vnode that represents the file that was mmap()ed, after its descriptor was close()d? Who caches this vnode, how and where? If this vnode is still 'alive' how is one able to physically move the executable file (mapped by the process) on disk? The file descriptor may or may not have been closed; that's irrelevant because the vnode pager is holding a reference to the vnode. The fact that the vnode has active references does not prevent you from moving the image within the volume or, for that matter, deleting the image off the volume. The vnode pager goes through VFS, and the VFS plug-ins are expected to deal with this sort of thing. This email sent to site_archiver@lists.apple.com