[Patch] Moving FD passing into the header
Marcel Holtmann
marcel at holtmann.org
Thu Jun 17 21:08:52 PDT 2010
Hi Colin,
> > To support file descriptors with this patch, it would be necessary to modify
> > the QDBusPendingReply in a way it wasn't meant to. I'd much rather simply add
> > a type that matches the signature, thus allowing for:
> >
> > QDBusUnixFileDescriptor fd = interface.asyncCall("something");
>
> I just don't think file descriptor passing is going to be common
> enough that it's necessary to get it down to a single line of code.
> Generally it's going to be down in the bowels of a few operating
> system components, or it will be wrapped inside another library like
> libpulse or whatever.
>
> > QDBusPendingReply<ReturnType> reply = interface.asyncCall("something");
>
> You can bind it as reply.wait(); reply.getUnixFileDescriptor(0); right?
so within BlueZ, obexd, oFono and PulseAudio we were planning to
actually make a lot of use of the fd passing. So I would say it is very
much common. And why not?
As I said before, I really like having the file descriptors as part of
the introspection data. Treating it as side channel or out-of-band data
seems pretty much wrong to me. It leads to hacks and other weird per
application agreements. While once it is part of the actual API, it can
be properly specified with common D-Bus introspection for methods.
Regards
Marcel
More information about the dbus
mailing list