29 Nov
2003
29 Nov
'03
4:57 p.m.
No scheduler that I've ever seen, written, or heard
of is going to
accept JACK's opinion on this subject as anything more than a strong
hint. The scheduler is the main loop of the entire system, *it*
decides what to run next.
i'm not trying to subvert the general operation of the scheduler. it
will still intervene when it needs/wants to.
what i want to stop is this: jackd is about running the process cycle,
and wants to hand control to the next client. it writes to a FIFO to
wakeup the next client, and goes to sleep waiting for the
"baton-passing" to wake it up again. however, for some bizarre reason,
the scheduler does not in fact run the next client, but does something
else instead.
put another way, i want JACK-the-system to keep running smoothly, even
though this includes crossing process boundaries. i don't want the
handoff of control that is implicit in running the process cycle to
return control to the scheduler "unnaturally".
Suggestions are welcome, but JACK truly does *not* know
for certain
what to run next. An interrupt could intervene and make a
higher-priority realtime process ready. Or, some other processor
could unlock such a thread. At the very least, there probably needs
to be code in the return path from the system call like the old Unix
logic of testing `runrun' and calling sched().
obviously, all these would remain in place and we would be doing
nothing subvert them. all we are doing is avoiding a schedule() caused
by jackd blocking-on-read and the next client being marked
runnable. both jackd and the next client should be considered "part of
the same system".
and just to be clear, i know this is a hack. i'm not pretending that
its good general purpose OS design (Apple already proved how
problematic it was). i'm trying to exploit the hackability that linux
is famous for to create a system really well tuned for "pro audio"
apps.
--p