29 Nov
2003
29 Nov
'03
1:51 p.m.
Paul Davis <paul(a)linuxaudiosystems.com> 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