29 Nov
2003
29 Nov
'03
10:20 p.m.
Roger Larsson <roger.larsson(a)norran.net> writes:
That's right. But, Paul and I have been working closely with this and
don't have much faith in the correctness of the 2.4 scheduler. Like
all non-trivial software components it has bugs, and getting them
fixed is difficult, if not impossible.
If next client is a RT process (SCHED_FIFO/RR) then it
WILL be selected
unless there is another RT process with higher priority, and lower than jackd
otherwice it would have been running in the first place.
I wish this were the true. But, I strongly suspect that it is not.
however, for
some bizarre reason, the scheduler does not in fact run the
next client, but does something else instead.
If this ever happens (and something else is not within in the priority range
new process ... jackd) then it is a scheduler BUG - and should be fixed! With the current scheme (OK, I am not quite up to
date)
you could write to the FIFOs of all ready processes before starting to
wait on the baton. [giving the sub processes different priority levels
will order them in case you have less processors than CPUs]
The current JACK implementation is completely single-threaded
regardless of how many real or virtual processors your system
possesses.
But, for some (relatively complex) graphs a multithread schedule would
be possible and desirable. So, theoretically your point is valid.
Maybe jack should handle the priorities for jack
clients - priorities is a
relative issue anyway... Then jackd could use this scheme when there
is only one client to run - and the lower priority clients when there are
several.
What problem does this solve?
--
joq