I'm very glad you hear you saying that, Alex. Those are indeed requirements my implementation will have to comply with, and I think it is totally feasible. It should improve realtime class latency very meaningfully without making any other parameter worse, although I also expect to achieve improvements in other parameters too. What I intend to do is to fully comply with the real time paradigm, by using some very efficient solutions I have been using to eliminate the risks of rt priorities misuses without breaking the paradigm. For me that's the easy thing (and proven already), although some related ppl at MS had a very hard time to understand it. The real challenge is to handle DPCs as preemptable real time threads, fully respecting assigned rt priorities. This is what would fix the problem definitely, but since currently DPCs are not preemtable, there is a possibility of breaking some drivers because access serialization or sync issues. But I expect this possibility will be in real world very low, as there should not be interactions between DPCs created by different drivers out of system control, and ultimately, the new scheduler will be very flexible, allowing to configure each driver's DPCs parameters separately, so DPC preemption could be disabled for each particular driver or for all of them. Probably the default config will be fully compatible with current behavior, but I expect that enabling DPC preemption by lowering the priorities of selected driver's DPCs should work fine with the most or almost all drivers. I could post a more concise description of the plan, but what I intend ultimately to achieve is a fully working and tested ntoskrnl that could run on regular xp or s2003 too (to verify full compatibility). So maybe instead of writing the details and discussing it, we may wait till I have it working and speak again afterwards. This way I won't be wasting the time of anyone else until the objectives are achieved and can be verified.
P.D: Win7 has again improved the scheduler in the right direction (and fixed a related big mistake in the Vista's WaveRT model), but the DPC thing still kills the latency and they don't want to change that. I already discussed it with some key ppl at MS: a few understood it, but even those didn't think there were good chances of convincing decision makers anytime soon. It is considered a very low priority, if not null at all. But for all pro audio manufacturers, and some other niches like automation and control, it is a top priority.
Best regards,
Jose Catena DIGIWAVES S.L.
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Alex Ionescu Sent: Tuesday, 22 December, 2009 04:10 To: ReactOS Development List Subject: Re: [ros-dev] MSVC
If your new implementation:
1) Is better than what Windows does today (hint: it's nearly lockless in Win 7, and O(1) since 2003) in every single way (ie: not sacrificing 50% of desktop users for 10% of server users).
AND
2) Maintains full compatibility with Windows applications (and I expect you to TEST this), drivers, etc in every way.
I promise you I will wholeheartedly support its inclusion in ReactOS.
In fact, I will do even more than just that.