Re: GVariant support for Unix fds (Was Re: GDBus/GVariant plans for next GLib release)

[Philip Van Hoof <spam pvanhoof be>]

On Thu, 2009-10-15 at 14:02 -0400, Ryan Lortie wrote:
> 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).

The fd-over-dbus is just the result of dup2(), right? Well actually
either F_DUPFD or F_DUPFD_CLOEXEC if I read Lennart's patches correctly.

What is the problem with using integer for that 'h' type?

Well, other than the fact that when you'd serialize the GVariant onto
disk, and deserialize it, then wouldn't the integer have any meaning
anymore. of course.

I guess that's inherent to this "fd over DBus" technique.

> 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.

Yah - something like that.

[cut]


-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be