kern_return_t semaphore_signal_thread(sempahore_t sem, thread_t
thread);
You can also try changing the secondary thread to fixed priority;
upping the importance of a timeshare thread only increases its
relative priority in the task. A background GUI task with base
priority of 46 and an importance of 17 will give the thread 63
priority, but it still uses timeshare policy. If it's a short-
running thread, you can switch it to extended policy (fixed, non-
timeshare). Beware of playing the priority game; first find out what
other threads are preempting yours in the scheduler. Change policy
first, then fixed, then up the priority gradually. The most
efficient app threading I've done makes use of lowering priorities as
a rule, rather than raising them. *
BTW, you can't block the CoreAudio thread prematurely (without
playing nasty mach port games), otherwise you could use the syscall
thread_switch(0, 0, thread) and jump directly into your secondary
thread.
* that statement is null and void, regarding the MacFOH DSP engine
daemon/server in user-space. ;)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
PerfOptimization-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
