Quoting Andreas Mohr andi@rhlx01.fht-esslingen.de:
Hi,
On Sun, Aug 29, 2004 at 10:07:18PM +1000, Con Kolivas wrote:
Audio runs as a separate thread outside of wine potentially through who knows how many layers as a combination of both process and kernel context so that's already complicating the issue by having a separate thread. X does the same again. So what the win32 game is doing under wine when it asks for audio or graphics to be done will be handled completely differently to windows. How blocking is done between the graphics and audio calls, when you have a highly cpu bound task (the game) as well is definitely complex and not just the kernel that is responsible here. Add to that the fact that wine itself runs a few threads and as I said before, it's a miracle it runs smoothly at all.
This shows that dynamic reloading of different schedulers is a very useful thing: if playing some game on Wine doesn't work with the currently used scheduler, you just load a specially adapted scheduler (say a "Wine" scheduler for close Windows scheduling compatibility ;) in order to have some great gaming session, and that's it. (of course it'd be useful to have a universally usable scheduler instead, but that is very difficult if not impossible to achieve)
Isn't Nick Piggin maintaining such a dynamic scheduler loader? I can't remember exactly, but I think he has patches for runtime switching between his single priority array scheduler and even staircase with single priority array. Please correct me, if I'm wrong.
Andreas Mohr