investigate new "fd" field in shm extension

[BurntSushi]

A new XML element fd has showed up in the protocol description for the shm extension.

A temporary fix in commit 490ec2a ignores this field.

What is it for? (File descriptor name?)

[pjanx]

The field indicates that you are supposed to send or receive a file descriptor over the Unix socket you're connected to (so long as it's not TCP). The other side can then e.g. mmap memory on it.

Let's talk about receiving for now, which might be the more complex part.

The mechanism has only been implemented in xcb and not Xlib, as Keith Packard says. Qt has started using the API fairly recently, in commit qt/qtbase@24adaa9

Of more interest to us is the possibly sole implementation. The crux of it is slightly complicated but boils down to: each time we get to read from the socket, accept sideband file descriptors as well using the appropriate syscall and pair them to what we see in upcoming replies, or wait for more FDs again if input data went too far ahead.

This is already doable in Go. godbus needs to do this, although the implementation is messy, or there's this example code making use of a standard API.

xgb.go looks like it could be extended with relative ease.

Attaching the respective part of xcb-proto 1.13 shm.xml for context:

  <request name="AttachFd" opcode="6">
    <field type="SEG" name="shmseg" />
    <fd name="shm_fd" />
    <field type="BOOL" name="read_only" />
    <pad bytes="3" />
  </request>

  <request name="CreateSegment" opcode="7">
    <field type="SEG" name="shmseg" />
    <field type="CARD32" name="size" />
    <field type="BOOL" name="read_only" />
    <pad bytes="3" />
    <reply>
      <field type="CARD8" name="nfd" />
      <fd name="shm_fd" />
      <pad bytes="24" />
    </reply>
  </request>