[systemd-devel] KDBus Signals and Timeouts
Kay Sievers
kay at vrfy.org
Tue Feb 25 12:32:18 PST 2014
On Tue, Feb 25, 2014 at 9:18 PM, Justin Brown <justin.brown at fandingo.org> wrote:
> On Tue, Feb 25, 2014 at 12:12 PM, Lennart Poettering
> <lennart at poettering.net> wrote:
>> On Tue, 25.02.14 10:41, Justin Brown (justin.brown at fandingo.org) wrote:
>>
>> And broadcast signals should never be large datagrams, but
>> only very short.
>
> Could you elaborate on this point? One of the major points of emphasis
> with kdbus seems to be performance. Why is that restricted to method
> calls? I understand that there would be implementation complexities in
> multiplexing memfds to all of the signal subscribers, but it seems
> like a desirable feature. A single source application that sends
> relatively large amounts of data (a few KB up to possibly several GB)
> to several third-party sinks seems like a natural use of memfds.
Broadcasting complex kernel objects like file descriptors inside the
kernel to many connections at the same time is outside of the focus of
kdbus. Things get really fragile very fast if we would allow such
things.
> As far as I can tell, the only way to accomplish this with kdbus would
> be for the source application to have a subscribe() method, so it
> could send methods to each sink. I apologize for asking such a
> simplistic question (I don't have my kdbus VM up and running yet.),
> but if I were to take this route, can the same memfd be used in
> multiple methods or would a new one need to be created for each
> subscriber?
You can send any kind of file descriptor many times, therefore also
memfds can be send many times.
Memfds are special that they can be used to carry *payload* of a dbus
message, not only be a naked fd. These memfds need to be sealed to get
accepted as payload, but they can be used multiple times too.
Kay
More information about the systemd-devel
mailing list