2 Dec
2009
2 Dec
'09
8:41 a.m.
On Wed, Dec 02, 2009 at 11:16:30AM +0100, Stéphane Letz wrote:
So does this mean than going into freewheeling should
be
handled in a special way: like dropping RT mode for
additional worker threads and so on (then when freewheeling
stops, you would have to setup RT mode again...)
See my other post - the easiest way would be to make the
main thread wait for the others.
We could even imagine that JACK could provide some
support
for this kind of requirement : allowing to define additional
worker threads, automatically handling priority change when
freewheeling on/off....
It could but I don't think it would simplify matters much.
Supporting many parellel period sizes *would* complicate
Jack a lot.
Paul Davis:
i doubt if applications with such architectures want
JACK
itself to try to micromanage this level of detail. they
already have to make their own decisions about thread
priorities.
These priorities maybe need some discussion.
The relative period sizes used by zita-convolver are
either 1:2:8:32 or 1:4:16:64. The first step is either
2 or 4, the others are always 4, and the choice of the
first step is made to make the longest one (if used)
always 8192.
In 1.0.0 each step would decrease the priority by one
relative to Jack's thread. In 2.0.0 this is different:
each doubling of the period will decrease the priority
by one.
This change ensures that threads using the same period
will have the same priority, even if they are not in
the same client. This is absolutely necessary in order
to make two or more such clients work together smoothly
and have 'fair' scheduling. This should become some sort
of 'standard' if more apps start using such schemes.
Threads doing disk-IO probably don't fall in this scheme,
I suspect they always use much larger block sizes, have
plenty of buffering and can run SCHED_OTHER.
Ciao,
--
FA
Wie der Mond heute Nacht aussieht !
Ist es nicht ein seltsames Bild ?