If the kernel grew a preempt_disable/preempt_enable function pair code could force the scheduler to avoid preempting the cpu via an interrupt out from underneath the code. Would serve a few purposes:
a) Could write code that expects a single run through without needing to disable interrupts. Good for a lot of test cases.
b) Could use the functionality to implicitly disable/enable around IRQ handlers, allowing refactoring away from 'bool reschedule' args to a variety of thread routines. This would be a massive cleanup.
Fairly easy to implement: Add a counter in the thread structure that simply counts up from 0 as you disable preemption and back down to 0 as you reenable it. At various inner context switch routines if the count is > 0 then skip a local reschedule and set a pending reschedule bool. When reenabling when the counter hits 0 if the pending reschedule is set then reschedule.
If the kernel grew a preempt_disable/preempt_enable function pair code could force the scheduler to avoid preempting the cpu via an interrupt out from underneath the code. Would serve a few purposes:
a) Could write code that expects a single run through without needing to disable interrupts. Good for a lot of test cases. b) Could use the functionality to implicitly disable/enable around IRQ handlers, allowing refactoring away from 'bool reschedule' args to a variety of thread routines. This would be a massive cleanup.
Fairly easy to implement: Add a counter in the thread structure that simply counts up from 0 as you disable preemption and back down to 0 as you reenable it. At various inner context switch routines if the count is > 0 then skip a local reschedule and set a pending reschedule bool. When reenabling when the counter hits 0 if the pending reschedule is set then reschedule.