>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
