[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <552FB5B4.9060700@zonque.org>
Date: Thu, 16 Apr 2015 15:14:28 +0200
From: Daniel Mack <daniel@...que.org>
To: One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
Havoc Pennington <hp@...ox.com>
CC: Rik van Riel <riel@...hat.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jiri Kosina <jkosina@...e.cz>,
Andy Lutomirski <luto@...capital.net>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Arnd Bergmann <arnd@...db.de>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Tom Gundersen <teg@...m.no>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
David Herrmann <dh.herrmann@...il.com>,
Djalal Harouni <tixxdz@...ndz.org>
Subject: Re: [GIT PULL] kdbus for 4.1-rc1
On 04/16/2015 12:08 AM, One Thousand Gnomes wrote:
>> When trying to split apart problems, for dbus it's important to keep
>> ordering guarantees.
>
> Yes I assumed that - minus disconnection/reconnect and running out of
> queue space. Some users also want priority queueing (with or without the
> guarantee for the same priority). Many of the other systems that can use
> a fast multicast messaging system have priority queues - which is one
> reason the existing POSIX messaging has priority.
And so does kdbus. By default, strict ordering is enforced when messages
are received, but optionally, that action may be constrained to messages
of a minimal priority. This allows for use cases where timing critical
data is interleaved with control data on the same connection. That's
described in kdbus.message(7), and is also covered by test cases.
Thanks,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists