[haiku-development] Re: Interesting thread priority assignments in media kit
- From: "Stephan Assmus" <superstippi@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 05 Aug 2008 09:42:22 +0200
Hi,
> > That's the basic idea behind realtime threads: they have to be designed
> > in a way that nothing can go wrong :-)
>
> We need to think very carefully about thread priorities. Tasks that
> use a lot of CPU should not normally be given a high priority.
>
> High priority should be reserved for those tasks that do their work
> very quickly and/or are interacting with hardware that has hard limits
> on timing.
>
> Decoding Video or Audio is not a high priority task. If your CPU is
> not up to the task of decoding at the rate required then raising the
> priority is unlikely to help.
>
> I like BeOS not just because it played media well, I liked it because
> it let me still use the system while playing media or anything else
> that I did. I always felt that I could do something else OR at the
> very least cancel the task I was doing not get locked out because
> suddenly the mouse or GUI were felt to be too low a priority while
> trying to squeeze out 1fps.
Well said, David, and I 100% agree. In video decoding, what needs high priority
is the thread that displays the video frames at the correct time,not the thread
that decodes them. So far, I haven't come across code that violates that
principle. The real time threads that for example the OSS media node uses are
the ones that need to pass tiny audio buffers at a precise time. They use very
low CPU, but need to wakeup at precisely the time they asked for. Something
which doesn't work well with the Haiku scheduler for some yet unknown reason.
Best regards,
-Stephan
Other related posts:
