Re: Yielding the processor in a kext?
Re: Yielding the processor in a kext?
- Subject: Re: Yielding the processor in a kext?
- From: Terry Lambert <email@hidden>
- Date: Fri, 7 Sep 2007 20:06:53 -0700
On Sep 7, 2007, at 4:41 PM, Régis Duchesne wrote:
Indeed, sched_yield() calls the swtch_pri() system call with zero as
only argument (the argument is not used by swtch_pri() so it does not
matter anyway). That in turn is connected to thread_block_reason()
which you cannot call form a kext but that is called from
thread_block()
which I suggested to you in my previous email so my answer of using
thread_block(THREAD_CONTINUE_NULL) may well turn out to be a winner
here!
I did the same investigation, but came to a different conclusion:
swtch_pri actually uses thread_block_reason(THREAD_CONTINUE_NULL,
NULL,
AST_YIELD) and the only difference is that:
1) thread_block_reason is not exported
2) AST_YIELD forces the timeslice of the current thread to 0
So by just using thread_block(), we might not surrender the timeslice.
I'll do some more real-life testing.
I have say 20 priority bands, and the thread I want to yield is off
all by it's lonesome at say P=3, and the things you want to yield to
are all in P=6, then going to the back of the line in the P=3 priority
band and rescheduling will get you exactly:
Anything in P=1? No. Look in next lower band.
Anything in P=2? No. Look in next lower band.
Anything in P=3? Yes -> Run thing in P=3 band again.
...in other words, you aren't yielding to what you think you are yield
to, unless you jack around the priority.
Your only input, other than using an FSA (which I see you say you
can't use because you are using a "black box thread") is to control
your thread priority.
-- Terry _______________________________________________
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