Subject: Re: [linux-audio-dev] another kernel patch?
From: Paul Davis (paul_AT_linuxaudiosystems.com)
Date: Sat Nov 29 2003 - 22:55:56 EET
>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
This archive was generated by hypermail 2b28 : Sat Nov 29 2003 - 22:52:56 EET