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 10:52:59 -0700
On Oct 27, 2006, at 9:40 AM, Rick Mann wrote:
On Oct 27, 2006, at 09:06 , Shawn Erickson wrote:
What problem is it solving? What is the use case for it.
Answer those types of question and use that information to file an
enhancement report with Apple.
I'm walking the VFS data structures looking for the processes that
have files open.
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.
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.
This gets you all the files currently "open" by a process. There are
other things that will hold vnodes referenced (pagers, disk images,
etc.) that you may want to detect as well.
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?
= 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>) |