On Sun, 21.06.09 11:09, Paul Davis (p...@linuxaudiosystems.com) wrote: > > 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.
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? > 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 _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
