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 20:11:10 -0700
On Oct 27, 2006, at 12:42 PM, Rick Mann wrote:
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.
I think Terry's done a pretty good job of elaborating what you'd need
to do in order to achieve your end goal.
As for speculation; Terry is one of the folks that maintains the code
and datastructures in question here. Happy now? 8)
The Darwin kernel lacks dozens of APIs that would allow safe
inspection of system state by forcing me to inspect the data
structures directly.
I'm not quite sure what that sentence was intended to mean. Another
way to think about it is that the Darwin kernel design avoids making
guarantees or creating/maintaining data that are not relevant to the
tasks it is attempting to accomplish. Offering thousands of APIs
(dozens for your specific application multiplied by hundreds of
similar, specific applications) would greatly hinder any sort of
development of the system. Apple decided, instead of freezing their
API set and stifling innovation both internally and externally, to
restrict what is guaranteed and then provide a way for third parties
to enhance beyond what they can do with the APIs at the cost of some
development overhead and lock-step release cycles.
It's not perfect, but the alternative (stagnation) would quickly
become much worse.
What you are looking for is a small facet of a very large and complex
problem (general service accounting). A decent solution to the
problem would require a great deal of work with little or no regular
practical application. Instead, you are tasked with a narrow
solution that solves your particular problem.
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.
Successive approximation is a remarkable tool.
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).
Any kind of work impacts performance; my point was simply that as a
matter of principle the Darwin code avoids doing unnecessary work.
Sure, you can argue that making every codepath that adds or removes a
reference to a vnode take another 50µs doesn't look like a
"significant" impact, but if you keep thinking that way you quickly
end up with a pig.
You might also count the number of cycles spent tracking that
information when the information is not actually used. The ratio of
useful vs. not-useful work would be billions to one, at least.
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.
Well, to be honest, you've brought your fair share as well. You're
getting answers from people that live this code on a daily basis; do
you expect them to react well when you rank your "speculation" over
their experience? Especially when you're essentially complaining
that despite everything else they are committed to do, you think that
something that serves your personal ends is more important?
= 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>) |
| | >Re: thread_t, uthread_t, at al.? (From: Michael Smith <email@hidden>) |
| | >Re: thread_t, uthread_t, at al.? (From: Rick Mann <email@hidden>) |