site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com We manage a bunch of (userland) threads that do some heavy computation (very similar to finite element analysis). For some reason that I'm not going to detail here, this management happens in a kext. Our goal is to make sure that none of these threads computes much faster than the others. That is, the more consistent the rate of progress across all these threads, the better the accuracy of the result of the computation. S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware _______________________________________________ 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... At 9:46 -0700 7/9/07, Régis Duchesne wrote: Are all of these threads in the same task (in the Mach sense of that word)? If so, you could use thread_policy_set (which is exported as a supported KPI) with the THREAD_PRECEDENCE_POLICY flavour to alter their priority relative to one another. Seems like that would get the job done in a fashion that's more likely to remain binary compatible in the long term. This email sent to site_archiver@lists.apple.com