Implement THREAD_PRIORITY_TIME_CRITICAL

Con Kolivas kernel at kolivas.org
Tue Apr 4 08:17:52 CDT 2006


On Tuesday 04 April 2006 22:42, Mike Hearn wrote:
> > What strikes me is that people are very happy to think that the kernel is
> > going to fix this problem. I have to tell you there will be no more
> > infrastructure put into the kernel anytime soon to help you here.
>
> I'm confused about this point. You say the kernel won't be changing
> anytime soon - does this mean you've given up on getting SCHED_ISO into
> the mainline kernels? 

It was something I toyed with until the realtime rlimits was put in place. 
There's no real need for it now. I support it in -ck because it's convenient 
for myself and users. It also depends on my staircase cpu scheduler and would 
need a complete rewrite for the mainline scheduler. Since the feature is not 
desired in mainline there's not much point me doing that.

> Can we _really_ not expect any support from the 
> kernel people here?

No. Again there is no reason an app should require some special kernel hook to 
work for something like a game. I _know_ it makes life easier but that's not 
the solution or else the kernel would be a complete mess of hooks for all 
sorts of applications that would like their own hook to make life easier.

> > I do not believe you are going to need real time scheduling to get audio
> > to work properly. This really is overkill in my opinion.
>
> OK. We'd love some alternative, if only because Alexandre seems dead set
> against anything that requires root access, even if that includes not
> running Wine itself as root.

I absolutely agree with him. Even the realtime rlimits is the wrong approach 
as it effectively gives the same sort of scheduling rights to starve a system 
that only root normally has.

> > Audio playback and decoding should not really use much cpu.
>
> I'm not even sure we can control that. Some games seem to set up their
> own mixing threads and such (looking at the SDL Win32 code it calls
> SetThreadPriority itself).
>
> Also this issue is wider than just audio, though this is where it hurts
> us the most. I guess there are other cases where a Windows program needs
> to raise thread priorities. Isn't Photoshop susceptible to scheduling
> differences?
>
> > Lastly, and this is not a comment about wine but all programming in
> > general, multithreading cannot be left up to chance.
>
> What do you suggest, that we find some way to make audio threads in Wine
> block/swap with more intensive threads? I'm having a hard time imagining
> how this would work ... we don't control what the other threads are
> doing, so ... hmmmm. I don't see any way to guarantee that every other
> thread will block on the audio thread often enough that the buffers
> never run down.

I know I didn't offer a solution, just standard rules for multithreaded 
application writing. The fact that wine is a compatibility layer rather than 
its own application is most of your problem. Is there no way wine could have 
an audio thread that does nothing but the compatibility component between the 
running win32 application and the alsa drivers? That would use very little 
cpu even if the win32 app internally does funky decoding and whatever else.

Cheers,
Con



More information about the wine-devel mailing list