[Xcb] [PATCH 4/8] Add xcb_send_fd API

Keith Packard keithp at keithp.com
Thu Nov 7 13:24:10 CET 2013


Uli Schlachter <psychon at znc.in> writes:

> Having thought about this some more in the shower, I would suggest to turn
> xcb_send_fd() into a private _send_fd() and instead add
> xcb_send_request_with_fds() (or something like that).

This isn't necessary; as I explained, the X server just holds onto FDs
that the client sends until a request consumes them. Yes, it has to deal
with clients sending unexpected FDs, there's nothing special about this.

> However, I also noticed that I don't know much about "unix fd magic", so could
> anyone please answer some questions:
>
> - What happens if we try to send FDs over non-unix sockets?

It fails.

> - Does the new sendmsg() call work correctly on non-unix sockets when no FDs are
> transmitted?

You'll note that sendmsg is *not* called when we have no file
descriptors to send.

> - Should we have some API to test if sending FDs works at all or if xcb just
> ignores the FDs?

I'm not entirely sure how you'd do that without actually trying to send
an FD, given that XCB can be handed a pre-connected file descriptor.

> - What happens with partial reads? Let's say we send 4KiB of requests to the
> server in one sendmsg() call and the last request has FDs attached. For whatever
> reason, the server only reads 2KiB of data from the socket. Will the FDs be
> handled correctly in this case? What if the FDs are for the first request
> instead of the last one?

The FDs are effectively attached to the first byte of the write; read
that bytes and you get all of the FDs sent there. So, if you perform
a 4kB write with 10 file descriptors, and read only 2kB, then you'll get
all 10 file descriptors as you've read the relevant byte.

> Oh and I just noticed:
> If HAVE_SENDMSG is not defined, shouldn't xcb_send_fd() close() the FD
> that it gets?

The X server won't advertise any requests which receive or send file
descriptors on a system which doesn't support SENDMSG, so I'm not sure
how interesting the precise semantics of this error case are. And, I
assume the BSD people will shortly figure out how to make this work on
their operating systems, which means that pretty much anything with
local applications will have working xcb FD passing.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/xcb/attachments/20131107/57635587/attachment.pgp>


More information about the Xcb mailing list