sys_indirect() [LWN.net]

sys_indirect()

Posted Nov 22, 2007 10:28 UTC (Thu) by nix (subscriber, #2304)
In reply to: sys_indirect() by drag
Parent article: sys_indirect()

I wasn't aware there was any intent to have apps migrate en masse to XCB (does anyone know of
anything other than Xlib that uses XCB yet?). What is more likely to be useful is to have
*widget sets* migrate, as they already implement most of what Xlib does themselves, and don't
need most of the rest except for the raw comms stuff which XCB provides.

As far as I know the XCB-based Xlib is here to stay.

to post comments

sys_indirect()

Posted Nov 22, 2007 22:36 UTC (Thu) by njs (subscriber, #40338) [Link] (1 responses)

GTK+ does use XCB in one or two obscure places, but most of it is still Xlib-based.  The big
advantage of Xlib-on-XCB is that it becomes possible to mix Xlib and XCB calls in the same
program, talking on the same X connection -- so you can have a gradual transition.  Aside from
toolkits themselves, interesting programs often have *some* direct calls to Xlib in addition
to all the ones that go through the toolkit, because toolkits don't expose everything.  (And
toolkits are explicitly architected to allow for this, e.g. there is a way to get an Xlib
Display* out of a GdkDisplay*.)  For some of those apps, being able to use a sane and
more-async-able API might well be valuable, and in general it is probably smart to use XCB in
new programs.

I have no idea what the equivalent for "libc migration" would be.  When would you want to use
two different libcs from the same program?  How would the compiler even know which version of
fork() you were trying to call?

sys_indirect()

Posted Nov 23, 2007 0:22 UTC (Fri) by nix (subscriber, #2304) [Link]

I suspect that the only way to `migrate' libcs would be a big bang with 
interface back-compatibility (which is, of course, exactly how glibc 
upgrades work). Nothing else works because of the presence of critical 
global data structures whose format must be understood by everything that 
accesses them (I'm thinking mostly of malloc() and free() here, but the 
exception unwinder is another example, which is why libgcc_s.so exists at 
all as opposed to just libgcc.a).