Skip to content

dynamic protocol bindings

Submitted by Havoc Pennington

Assigned to xcb mailing list dummy

Link to original bug (#29743)

Description

It would be useful to have fast runtime access to something like the XML protocol descriptions (but converted to a binary format), similar to gobject-introspection. This would allow language bindings to dynamically generate wrappers on the fly. It would also allow things like xtrace or more one-off debug hacks to use the protocol descriptions.

Even the C binding would have the option to go dynamic. The protocol bindings are not tiny: $ size /usr/lib/libxcb-glx.so text data bss dec hex filename 64447 2616 8 67071 105ff /usr/lib/libxcb-glx.so

In theory, each request could be nothing but a call to a dynamic invoker like this:

xcb_send_request_dynamic(connection, flags, request_description, ...);

where "..." would be the args currently passed to the wrapper, and "request_description" would be the binary equivalent of the xml description.

Some notes on this:

  • it would be nice to add the request name to the current xcb_protocol_request_t for debugging purposes. supporting lookup of request description given major and minor opcode, for example, would be super useful.

const xcb_request_description_t* xcb_describe_request(int major, int minor)

printf("got request %s\n", xcb_describe_request(major, minor)->name);

  • ideally request_description would avoid any references to other symbols. I think e.g. the address of the extension id in xcb_protocol_request_t creates relocations. Qt's moc compiler generates descriptions as one huge string, for example, so there's only one symbol and it points to the read-only data section.

  • in principle the xcb protocol wrapper libraries could just be the requests description blob in the library itself, plus headers with macros expanding to xcb_send_request_dynamic. for compat reasons you'd have to make the request-sending APIs functions instead, but they could just be functions that invoke xcb_send_request_dynamic() and nothing else. If the libraries contained only one read-only const symbol (the request description) then they would have notably less overhead than they do now. That's not back compatible, but even reducing each function to be just an invoke of xcb_send_request_dynamic() could result in some nice shrinkage.

  • a dynamic setup would perhaps be slightly slower, but the reduced size probably matters more in the real world, and it ought to be pretty fast

  • the dynamic setup makes non-C language bindings fixed-size, instead of a multiple of the number of requests the binding supports. (same principle as gobject-introspection)

  • http://ometer.com/parallel.html could be used to deprecate the static C bindings

  • whatever happens with the C bindings, exporting the "introspection data" at runtime instead of in effectively static-only (due to efficiency issues) XML files would be very useful for debug tools and language bindings.

Does this sound reasonable or does it conflict with some XCB goals?