On Nov 27 10:14, Christian Franke wrote: > Corinna Vinschen wrote: > > On Nov 25 21:20, Christian Franke wrote: > > > Corinna Vinschen wrote: > > > > - Isn't returning SCHED_FIFO sched_getscheduler() just as wrong? > > > Definitly. SCHED_FIFO is a non-preemptive(!) real-time policy. Windows > > > does > > > not offer anything like that to userland (AFAIK). > > > > > > https://man7.org/linux/man-pages/man7/sched.7.html > > > > > > I wonder whether there was a use case for this emulation when this module > > > was introduced in 2001. > > Just guessing here, but using one of the RT schedulers was the only way > > to enable changing the priority from user space and using SCHED_FIFO was > > maybe in error. > > > > > > Shouldn't that be SCHED_OTHER, and sched_setscheduler() should check > > > > for that instead? Cygwin in a real-time scenario sounds a bit > > > > far-fetched... > > > Agree. > > > > > > Note that SCHED_OTHER requires sched_priority == 0, so most of the > > > sched_get/set*() priority related code would no longer make sense then. > > This is the other problem. Changing this to SCHED_OTHER sounds like > > dropping potentially used functionality. Maybe we should just switch to > > SCHED_RR? > > Yes, it at least would be closer to what windows does. It is still > non-preemptive from the point of view of lower priorities. I don't know what > the Win32 *_PRIORITY_CLASSes actually do.
Who does? :} > As far as I understand the related documentation, a more sophisticated > emulation (aka fake) of SCHED_* would be: > > - Allow to switch between SCHED_OTHER (default) and SCHED_RR with > sched_setscheduler(). > > - If SCHED_OTHER is selected, change PRIORITY_CLASS with setpriority() and > ignore (or fail on?) attempts to change sched_priority with > sched_setparam(). > > - If SCHED_RR is selected, ignore setpriority() and change PRIORITY_CLASS > with sched_setparam(). > > Possibly not worth the effort... Why not? It should probably also allow SCHED_FIFO for backward compat, since, in a way, it doesn't really matter anyway. This would be nice for 3.6. And I think your patch here should go in as is, just with the release message in release/3.5.5 so we can cherry-pick it to the 3.5 branch. Thanks, Corinna
