moving file descriptor passing into a header

[Ryan Lortie]

Hi Lennart

On Tue, 2010-04-13 at 23:36 +0200, Lennart Poettering wrote:
> So what you would take out there is that you can actually attach context
> to specific file descriptors and hence meaning and instead have them in
> list without context except "they belong to this message".

That's a somewhat prejudicial way of looking at it.  All we're really
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.

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.

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

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

  2) GVariant does support the 'h' type and has for a while.  The stable
     release of glib 2.24 contains this support.  I'd be willing to roll
     this back (either by way of deprecation or outright removal -- I
     doubt anyone would notice).

> Is this about portability? or about out-of-fd handling? what is
> this about?

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.

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


Cheers