21 Jun
2009
21 Jun
'09
8:15 p.m.
On Sun, 21.06.09 11:09, Paul Davis (paul(a)linuxaudiosystems.com) wrote:
Simpler solutions? I am listening! What would a "simpler solution" be,
that doesn't suffer by all the issues I pointed out in the README?
Also, what's baroque with this? I mean, really, this offers an API of
two tiny functions. Not sure why you'd call that baroque?
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).
Dunno. SCHED_ISO would certainly be nice, but having that wouldn't
solve the problem really either. Also in the end you need to supervise
RT processes anyway, which is heavily bound to admin policy and
will hence probably always require some userspace part.
And rtkit is just a tiny piece of software that only requires minimal
additions to client code to be useful. So if one day it turns out it
won't be necessary anymore then we can simply remove without much
hassle. This doesn't have to be a solution for the eternity.
Either way, it seems like something that makes things
more complex
on every level, not less.
Ah yeah? How so? What's complex? Adding a single #ifdef'ed fucntion
call to your code? I mean, really, there's not much left that could be
simpler than that.
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.
Uh? I see one function call for mach's setThreadToPriority
vs. .... one function for pthread_setschedparam(). Uh? Where's the
practical difference?
You're adding a new API for this that will not be
backwards
compatible beyond a kernel change that has only just been made.
So what? How does that matter? New features you only get with new
code.
And it's not that adding support for rtkit to some software would
break anything that worked previously. RLIMIT_RTPRIO will still work
just fine, if people set it. All rtkit is about is that we can enable
RT scheduling for media applications out-of-the-box on newer Linux
distributions. If 'out-of-the-box' doesn't matter to you then
fine, I am pretty sure that distributors who ship your software do
care about it. I am pretty sure that in Fedora we would simply patch
jack_acquire_real_time_scheduling() to query rtkit if
pthread_setschedparam() fails with EPERM. It's a tiny
patch. However, I really don't see why you wouldn't want to merge a
jack patch like that to jack's official sources as long as it is a
compile-time option. I am pretty sure the distributors would be
thankful for that.
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.
If people can make a good case for SCHED_FIFO, then fine, we can add
that to rtkit.
Personally, I believe that RR vs. FIFO is not so much a decision that the
programmer should make. I think this is more a decision for the admin,
because this influences fairness between consumers of RT.
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.
Uh. First of all, it's hard to find a POSIX system these days that
doesn't have D-Bus installed. All big distributions ship it. All big
desktop environments require it. Even non-Linux systems that are from
the last 5 years ship it. To find a system that lacks D-Bus you need
to go to niche distributions which are specifically designed to avoid
sytems such as D-Bus. But I seriously doubt they really matter.
D-Bus is simply an API for IPC, one that happens to have an adoption
of 100% on relevant POSIX implementations. If you try to avoid D-Bus
for IPC when coding for those systems then all you do is reinventing
the wheel over and over, duplicating a substantial amount of code, and
potentially buggy code. At this point in time it's not D-Bus that is
bloat but it is the applications that still implement their own
non-trivial IPC system that include unnecessary bloat.
Finally, I believe your insisting on POSIX is a lost cause anyway,
because it is a fictitious OS interface. It's a good guideline, but
limiting yourself to it will limit the usefulness of your application
drastically because you don't make use of a real operating system's
feature set anymore, but to one that does only exist as an idea, as
the least common denominator of a few OSes that are already quite aged
these days. Also, at an ironic side note, your own
jack_acquire_real_time_scheduling() implementation as one example is
not even POSIX compliant. You print pthread_t as a %d. POSIX is pretty
explicit that pthread_t does not have to be an int, not even an
arithemtic type, but could be a struct.
In summary: I am not asking you to adopt this replacing some of your
current code. All I kindly ask for is to ease the distributors life by
adding a tiny bit of fallback code that does a tiny call into rtkit in
case sched_setschedparam() fails with EPERM and is #ifdef as __linux__
&& HAVE_DBUS and is also contorollable as a compile-time configure
option.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4