site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com So by just using thread_block(), we might not surrender the timeslice. I'll do some more real-life testing. 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. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... 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 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: ...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. This email sent to site_archiver@lists.apple.com