Re: thread_t, uthread_t, at al.?
Re: thread_t, uthread_t, at al.?
- Subject: Re: thread_t, uthread_t, at al.?
- From: Rick Mann <email@hidden>
- Date: Fri, 27 Oct 2006 12:42:33 -0700
On Oct 27, 2006, at 12:21 , Michael Smith wrote:
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.
I'm not sure I agree with this assertion. I don't think it would be
asking too much. The Mac OS (Carbon) file system was able to do it,
and I hardly think that support could be blamed for any significant
slowdown. (Mind you, this is speculation).
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.
I mean, it's not reliable as an indicator of which process is keeping
a volume busy, my end goal.
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
I don't think 30 years and thousands of engineers necessarily leads
to better code. In fact, I think most of the time it leads to poorer
code. The Darwin kernel lacks dozens of APIs that would allow safe
inspection of system state by forcing me to inspect the data
structures directly. In the few hours I spent looking at the source
over the last day, I've found a great deal of sloppiness, due mainly
to the fact that this code has evolved over decades and has been
altered by hundreds of people, people who didn't all share the same
vision of what the code base was or should be.
If you haven't already, I recommend you grab a copy of Amit Singh's
book. It's very good.
I have it. It's what led me to try this approach.
All I want to so is add some very useful functionality that existed
in the pre-Mac OS X Mac: the ability to tell who's got a volume open
when you try to unmount it via the Finder. I can't actually fix the
Finder, but I can come close with a contextual menu plugin. The only
mechanism to determine this is lsof, which is slow and unreliable (it
does not detect files opened by the Kernel). I was hoping to find
another way.
I'd be willing to experiment with adding support to the Kernel & BSD
to keeping track of these things as files are opened and closed (as I
said above, I don't agree with your assertion that this needs to have
any significant impact on performance). However, I'm finding it
ridiculously difficult to actually build from Apple-provided sources,
and as far as I can tell, OS X 10.4.8 Intel sources aren't even
available.
I was hoping to find support here, and I've found some. Mostly enough
to keep me from pursuing a dead-end. But I've also met with a certain
degree of resistance and arrogance.
--
Rick
_______________________________________________
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>) |
| | >Re: thread_t, uthread_t, at al.? (From: Michael Smith <email@hidden>) |