site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Hi Régis, So by just using thread_block(), we might not surrender the timeslice. I'll do some more real-life testing. But yes, real-life testing will show what it really does. (-: Best regards, Anton -- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/ _______________________________________________ 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 8 Sep 2007, at 00:41, 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 Correct but due to 1) it is irrelevant as I cannot see any way to specify AST_YIELD from a kext (I am assuming you will not manage to get Apple to export thread_block_reason()) and as to 2) I am not convinced it matters. Looking at the code, thread_select() only cares about the timeslice value (which is the only thing set to zero by AST_YIELD) when the current process priority is at REALTIME so that is not an issue (unless your threads run realtime I suppose but I am assuming here that they are not). Further choose_thread() does not care about the timeslice at all. It unconditionally switches to the next thread in the run queue even going to the trouble of stealing a task from a different CPU run queue if needed. So perhaps what actually happens is that calling with AST_YIELD kills the current time slice and starts a new one whereas AST_NONE (used by thread_block()) hands the remainder of the current time slice to a new thread. Again, please take what I say with a pinch of salt as I am not exactly an OSX scheduler expert having never looked at the code before this evening! This email sent to site_archiver@lists.apple.com