moving file descriptor passing into a header

[Lennart Poettering]

On Tue, 13.04.10 17:50, Ryan Lortie (desrt at desrt.ca) wrote:

> talking about here is a new type that makes dealing with file
> descriptors slightly more convenient.
> 
> There is nothing to prevent you from using an 'i' instead of a 'h' and
> using that as an index into the array of file descriptors that would be
> sent alongside the message.  You'd know from the type of the message if
> a particular 'i' were conceptually representing a file descriptor or an
> actual integer in much the same way that you know if a particular 'i'
> represents a width in pixels or a timeout in milliseconds.

Well there is also nothing that prevents you from using a char array to
represent about any classic type.

We provide marshalling in D-Bus. And that's good that way, there are
many good reasons to do that. If we support a new type, then we should
support marshalling/unmarshalling for it. I am not convinced that in the
case of fds it is a good choice to leave the marshalling to the user --
especially since in the case of fds it is not trivial to do things
properly.

Also note that an fd is internally nothing but an index into an fd
array. You are welcome to map that index as a magic int in GVariant.

> It's my opinion that it's not worth corrupting the type system with a
> type that is only available/meaningful on some platforms in order to
> achieve this very slight increase in convenience.

"corrupting"? is that so?

So this is about portability. Let's just be honest, D-Bus is only
relevant on Unix systems. It's nice if the things work on non-Unix
systems as well, but uh, maybe that shouldn't influence us too
much. Love's labour's lost.

Especially given that that to my knowledge D-Bus on Windows is mostly still a
pipe dream, if I understand correctly.

> > Could you explain to me what the problem is with considering an fd a
> > complex data type like any else that requires a special "deep" copy
> > instead of a simple memcpy()?
> 
> D-Bus has no other types like this.  Everything else can be serialised
> on a wire (any wire).

Well, the way I see this (and the way I implemented this in dbus) is
that there are simply two streams of data: the payload stream and the fd
stream. Thinking that way makes handling these things very easy as you
follow much the same logic everywhere except that you have two
serializing streams instead of one.

> > What exactly makes it so hard for type systems like GVariant to support
> > this? I mean, it supoports other "deep" types, I presume, and is this
> > one really tthat differnt?
> 
> Two things:
> 
>   1) GVariant supports no other 'deep types' unless you argue that DBus
>      object paths are deep types (since they also refer to things that
>      are not directly contained in the message).  In this case there is
>      no special treatment, though -- they're just strings with a special
>      constraint on their content.

Well, does GVariant demarshal D-Bus messages itself or does it rely on
libdbus for that?

I presume the former? If so, wouldn't it be sufficient if we chose to
simply export _dbus_message_get_unix_fds() for you (which we might want
to do anyway)? If so, then you could just deviate slightly when
demarshalling in GVariant from libdbus and hand out the fd
index instead of the fd itself?

That way an a fd in GVariant would be nothing but a int, with a special
"constraint" (more an indication: 'hey! it would be smart to use this to
look up an fd in the fd table of the msg!'), much like object paths?

And that way we could keep the fd typesafety fully around in marshallers
that support it and in a minimal form in marshallers that don't -- Like
GVariant, where you could memcpy() your fd indexes around as you wish,
without having to think about dup(), and where it would be left for the
user to manually resolve that indirection via
dbus_message_get_unix_fds() (or even a simpler API around that that just
returns one of the fds at an index, instead of them all).

Of course this comes at the slight price that the dermarshallers in
libdbus in GVariant would feel a bit different. But I bet they do
anyway...

> This is taking the D-Bus type system from something that is capable of
> representing only values that are normally considered to be serialisable
> and introducing an extremely large exception to that rule.

As mentioned I don't really see that as an exception. It's just two
streams of data instead of one.

> It's also about portability.  The topic for discussion came up today,
> actually, because David was discussing feature negotiation in the DBus
> protocol.

But feature nego has nothing to do with this particular question unless
you want to remove fd passing support entirely from dbus, which I am (of
course) strongly against.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4