fre, 14,.01.2005 kl. 13.06 +1100, skrev Con Kolivas:
Well the scheduler is not going to be rewritten any time soon (trust me, I've tried :P). Tell me what remaining requirements your threads have that you are unable to achieve at the moment and I'll see if I can help with my understanding of the priority system as it is, in a generic way that hopefully will work across scheduler designs.
The biggest problem is that there is no way to say to the kernel that one thread is more important than another without permanently renicing all other threads. A potential kernel solution to the problem would be to implement process scoping in the kernel, i.e.
pthread_attr_setscope(attr, PTHREAD_SCOPE_PROCESS)
and then allow threads scoped this way to be set to high priority, since with a process scope, these threads should only preempt other threads in the same process (i.e. Wine), not threads run by other Linux apps, and thus the security concerns of elevated priority threads are irrelevant.
Allowing a process-scoped thread to set the scheduling policy to SCHED_RR in order to inhibit the kernel's interactivity priority boost system would also help.