Re: thread_t, uthread_t, at al.?
Re: thread_t, uthread_t, at al.?
- Subject: Re: thread_t, uthread_t, at al.?
- From: Michael Smith <email@hidden>
- Date: Fri, 27 Oct 2006 12:21:32 -0700
On Oct 27, 2006, at 11:05 AM, Rick Mann wrote:
On Oct 27, 2006, at 10:52 , Michael Smith wrote:
That's doing it the hard way, as there is a one-to-many
relationship between vnodes and file descriptors and as I recall
no straightforward way to go from the former to the latter.
Hmm. I guess you're telling me that a process would own a file
descriptor, but but not a vnode. Crap, this throws a wrench in my
works.
"ownership" is a poor way of thinking about the concept.
The vnode represents the "file"; it is global in scope, and has
global context that must be consistent regardless of who is looking
at it.
A file descriptor is process-wide in scope; it has context that must
be consistent across any thread in the process, but should not be
affected by any other process.
The internal implementation of the file descriptor is actually more
complex than this; they are intentionally broken into several parts
to accomplish a number of additional objectives, but since you want
to associate open files with processes, you need to consider the 1:1
view of the relationship, not the 1:m side.
Really, you want to take this on from the consumer side, not the
provider side. Walk the descriptor table for each process to
enumerate files that are held open with a descriptor. Then walk
the memory map for each process, tracking down the mapped VM
objects and following them back to their respective pagers to work
out whether they are backed by a file that is not otherwise open.
I believe this is what lsof does, and it's very slow.
There is a reason that lsof does this. The information you're
looking for is not maintained by the system; it would be expensive to
do so, and the work would almost always be wasted.
So far though, I can't think of anything that involves tracking
the process to which a thread belongs in what I've outlined
above. You aren't making an assumption about v_owner, are you?
Looking at the sources, v_owner is either null or it's
current_thread(), but I guess that can change as a file is
accessed, so that won't be reliable at all.
Modulo bugs in the code, it is completely reliable. It's just not
what you thought it was.
Coming from over a decade of Mac OS development, I'm less and less
impressed with the overall design of Unix/Darwin APIs and code.
This is very frustrating.
I understand your frustration, especially given the clean break
between the legacy Mac OS and Darwin, but I don't think that being
insulting about it is going to help anything.
There is more than thirty years times thousands of engineers worth of
design and experience embodied in the Darwin kernel, and to say that
you're "not impressed" because you don't understand it and/or it
doesn't satisfy your presumptions ... it's like saying you're not
impressed by the Hoover Dam because it's "just concrete". 8)
If you haven't already, I recommend you grab a copy of Amit Singh's
book. It's very good.
= Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
| References: | |
| | >thread_t, uthread_t, at al.? (From: Rick Mann <email@hidden>) |
| | >Re: thread_t, uthread_t, at al.? (From: Michael Smith <email@hidden>) |
| | >Re: thread_t, uthread_t, at al.? (From: plumber Idraulico <email@hidden>) |
| | >Re: Re: thread_t, uthread_t, at al.? (From: "Shawn Erickson" <email@hidden>) |
| | >Re: thread_t, uthread_t, at al.? (From: Rick Mann <email@hidden>) |
| | >Re: thread_t, uthread_t, at al.? (From: Michael Smith <email@hidden>) |
| | >Re: thread_t, uthread_t, at al.? (From: Rick Mann <email@hidden>) |