[PATCH] Cygwin: sched_setscheduler: allow changes of the priority

[Christian Franke]

Hi Corinna,

Corinna Vinschen wrote:
> Hi Christian,
>
> On Nov 25 15:00, Christian Franke wrote:
>> Corinna Vinschen wrote:
>>> Fixes: ...?
>> ... the very first commit (cgf 2001) of sched.cc :-)
>>
>> New patch attached.
>>
>>  From e95fc1aceb5287f9ad65c6c078125fecba6c6de9 Mon Sep 17 00:00:00 2001
>> From: Christian Franke <christian.franke@t-online.de>
>> Date: Mon, 25 Nov 2024 14:51:04 +0100
>> Subject: [PATCH] Cygwin: sched_setscheduler: allow changes of the priority
>>
>> Behave like sched_setparam() if the requested policy is identical
>> to the fixed value (SCHED_FIFO) returned by sched_getscheduler().
>>
>> Fixes: 6b2a2aa4af1e ("Add missing files.")
> Huh, yeah, this is spot on.  I wonder if it would make sense to change
> that to 9a08b2c02eea ("* sched.cc: New file.  Implement sched*.")
> though, given that was the patch intended to add sched.cc :)))
>
> Sorry, but I have to ask two more questions:
>
> - 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.


>    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.

A related interesting snippet which I don't understand:
sys/sched.h:
#if defined(__CYGWIN__)
#define SCHED_OTHER    3
#else
#define SCHED_OTHER    0
#endif

> - Don't you want this patch in 3.5.5?  I'd merge the other patch
>    into 3.5.5 anyway...

OK.

-- 
Regards,
Christian