simon.mcvittie at collabora.co.uk
Thu Nov 8 03:04:07 PST 2012
Martin Vidner wrote:
> note that the integers in the message are not the FDs
For clarity: this is a statement about the D-Bus "wire protocol" (what
goes over the Unix socket), as documented in the D-Bus Specification.
D-Bus implementations and bindings might follow this, or might do
something else; refer to the documentation of your D-Bus implementation
to find out how it represents file descriptors.
The C API presented by GDBus is fairly close to the wire protocol in
this respect: you get a GVariant of type G_VARIANT_TYPE_HANDLE, whose
numeric value is an index into the GUnixFDList attached to the message.
For instance, if g_variant_get_handle() returns 5, that's not your file
descriptor: the actual file descriptor is whatever is returned by
g_unix_fd_list_get (list, 5, &error).
The C API presented by libdbus is different, and is what Thiago is
referring to here:
On 07/11/12 23:57, Thiago Macieira wrote:
> library converts the index into the Unix ancillary data to a real file
This is specifically a statement about libdbus.
Bindings that wrap libdbus might follow libdbus' behaviour, or they
might do something else entirely. For instance, dbus-python will give
you a dbus.UnixFd object containing the fd, which is automatically
closed if the UnixFd object is destroyed without calling its take() method.
> which you *must* close.
More precisely, what libdbus returns is a new file descriptor similar to
the one returned by the C functions dup() and open() (POSIX::dup() and
POSIX::open() in Perl): so you must close it, unless you specifically
want it to remain open (either because you're still using it, or you're
deliberately "leaking" it).
"systemd inhibits the power key until I close the fd, and I want the
power key to be inhibited until I exit" is one of the few reasons why
you might want to deliberately "leak" a file descriptor.
More information about the dbus