On Thu, 2009-10-15 at 12:38 -0400, David Zeuthen wrote: > Yeah, I think we need to support this from the get-go. > > Anyway, at the end of the day, UNIX fds are just integers so if you > require that users (such as GDBus itself and apps using GDBus) keep the > fds alive until the method/signal has been sent/received you should be > able to treat them as such. Anyway, it's probably more complicated than > this.
I talked to Lennart on IRC and the 'h' type, as serialised, isn't a file descriptor so much as it is an index into a table of file descriptors that are stored separately (in a separate part of the DBusMessage). Keeping this in mind, we could support this by doing the same thing with GDBus -- support 'file descriptor array offset' as a special type of integer in GVariant (much like 'o'bject path is a special type of string) and have a GDBus call for send_with_file_descriptors() or such. Lennart mentioned that he thinks that it's a bad idea that the dbus_message_marshal stuff was ever added to libdbus, and that the fd-passing stuff in libdbus will break if you try to use those functions. If we ever want to make a more efficient GVariant-to-DBus conversion process we'll have to turn it off for the case where fd's are present -- that's another reason for having a separate call, maybe. I don't think we would want to have any more 'deeply integrated' support than that, for a lot of reasons: Lennart mentioned that this only really works on Linux (and of course, only works if you connect to the bus using Unix sockets). There's also the concern of what it would mean to serialise a GVariant that contains an fd (to dconf, to the registry, to text format, to XML, or to anything else). Cheers _______________________________________________ gtk-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-devel-list
