On 04/09/2014 13:37, Miro Kropáček wrote:
I believed that FreeMiNT never preempt tasks in supervisor mode, but
is it still true for NFS.XFS? And what happens when NFS.XFS calls
other kernel services?
This is a very good point. I shared the same belief, perhaps there's an
exception for stuff like XaAES and during this exceptional state also
the NFS code gets executed, as a side effect.
From what I understand, *preemptive* multitasking is disabled in supervisor mode, but *cooperative* multitasking is still possible in kernel modules when calling blocking kernel functions or s_yield() to manually give time to other tasks.
Cooperative multitasking is not a bad thing, tasks just have to avoid hogging the CPU during long operations. This should work fine as long as tasks are carefully written.
On the other side, preemptive multitasking (which happens on FreeMiNT for user programs) is more permissive: programs does not have to care about other ones, the tasks are authoritatively switched when they try to hog the CPU.
That lead me to a further consideration. User programs which call Super() to switch to supervisor mode and do infinite loops without doing any GEMDOS call (ex: demos) prevent multitasking: they hog the CPU and other tasks can't execute. If they detect FreeMiNT, they could call Syield() on each VBL for example, so other tasks could execute. On other words: if I understand correctly, supervisor programs could do multitasking in a cooperative way.
Now I understand better that phenomenon: if you use GEM=ROM to run the ROM AES from FreeMiNT, the keyboard does not work. I think it is because the AES runs in supervisor mode, and does not call the GEMDOS regularly. As a result, the keystroke handling (which seems to require multiple tasks in FreeMiNT) can't occur. I remember that people indicated a special accessory which called Syield() regularly. As far as I understand, the desktop accessories run inside the AES task (same process), so that's a trick to ask the AES to call Syield() regularly.
-- Vincent Rivière