Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Paul Davis <paul-dDzkXPnfpdxaomM2pvQuqZqQE7yCjDx5 <at> public.gmane.org>
Subject: Re: [LAD] [ANNOUNCE] Safe real-time on the desktop by default; Desktop/audio RT developers, read this!
Newsgroups: gmane.linux.audio.devel
Date: Sunday 21st June 2009 15:09:12 UTC (over 8 years ago)
On Fri, Jun 19, 2009 at 2:13 PM, Lennart
Poettering wrote:
> Heya,
>
> Just a quick announcement:
>
> I just moved into Fedora Rawhide a little daemon called "RealtimeKit"
> which will be enabled by default, and since it is now a dependency of
> PulseAudio and things work how they work this will then not only be
> available in Fedora 12 but also sooner or later in the other
> distributions as well, installed by default.
>
> So what does this do? It's a simple policy daemon that hands out
> SCHED_RR scheduling to normal user processes/threads that ask for it.

This appears to be a baroque mechanism designed to solve a problem
suspectible to vastly simpler solutions. Alternatively, one could see
it as a baroque mechanism designed to solve to solve a problem that
really needs a much more sophisticated solution (i.e. better
scheduling policies). Either way, it seems like something that makes
things more complex on every level, not less. Take a look at the code
in libjack/thread.c and compare and contrast what is necessary to get
a realtime thread on Linux (already) compared to OS X. You're adding a
new API for this that will not be backwards compatible beyond a kernel
change that has only just been made. I cannot imagine wanting to use
this mechanism. You also seem to have assumed that everyone agrees
that SCHED_RR is the correct policy, rather than SCHED_FIFO.
Reasonable people still disagree about this. Finally, as Chris said -
many of us are writing apps that target multiple platforms, and adding
a new dependency on non-POSIX systems like DBus in order to get done
things that are supposed to be possible with the POSIX API ... well,
it gives some of us a slightly wierd feeling at the very least.

--p
 
CD: 4ms