Paul Davis <[EMAIL PROTECTED]> writes: > the problem is not (just?) the time that the scheduler takes. its that > its decision making process is opaque. when jackd runs, it knows for > certain which pid/tid to run next. we don't want to cede control of > that back to the kernel scheduler.
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. 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(). > i think i've mentioned before that i'd like to do a paper on JACK > someday for Usenix, with a focus on its capabilities for "user space > cooperative real-time scheduling", or something like that. Sounds good. -- joq
