[linux-audio-dev] another kernel patch?

[Paul Davis]

>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