Re: [LAD] [ANNOUNCE] Safe real-time on the desktop by default; Desktop/audio RT developers, read this!

On Mon, 22.06.09 16:34, Adam Sampson (ats@email-addr-hidden) wrote:

> > There is not compile time dependency on rtkit and no runtime
> > dependency either.
>
> Yes, there is a runtime dependency on RealtimeKit -- else there would be
> no point in having it in the first place! If I'm building an operating
> system package for an application that wants realtime priority, then my
> package has to have an explicit dependency on RealtimeKit as well as
> D-Bus.

No.

rtkit is just an option. If distros install it, then you can use
it. If they don't then don't. The reference client code will magically
start to work if rtkit is around. If it isn't then there's still
RLIMIT_RTPRIO.

Really, there is no dependency.

> > Also, the client reference implementation is tiny. it just wraps two
> > method calls. Trivial stuff.
>
> It's neither trivial nor tiny -- rtkit.c is a bit over a hundred
> non-comment/blank lines of code. The entirety of thread.c in libjack
> (which handles getting realtime priority on a variety of operating
> systems, among other things) is less than two hundred. This should be in
> a library, *not* copied-and-pasted into multiple places; that's a
> maintenance nightmare waiting to happen.

The reference implementation is relatively verbose, because it is
... a reference implementation. You can implement the real-time method
invocation in one call to dbus_message_new_method_call() followed by
dbus_message_append_args(), followed by
dbus_connection_send_with_reply_and_block(). Done.

> I should be clearer here that I think the RealtimeKit approach is
> actually pretty sensible on Linux, and I don't have any objections to
> using D-Bus. I just think it's important to recognise that this approach
> is not appropriate for all platforms, and providing a more conventional
> library interface would be more convenient for programmers, more
> portable, and generally better software engineering practice.

I guess we have to agree to disagree here then.

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@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev