On 23 February 2011 11:15, Rami Ylimäki <[email protected]> wrote: > On 02/22/2011 11:26 PM, [email protected] wrote: >> >> Although wrong, our code has been working well enough for us to get >> useful information. If someone is able to point out a reason why >> this now works less successfully than previously, then that would >> bump up the priority at our end. > > By superficially looking at the Xlib code, the behavior in older Xlib > version (1.3.3) is different depending on whether Xlib is configured > --with-xcb or --without-xcb. When Xcb is disabled, error handler is called > with display unlocked and _XReply seems to be prepared to handle requests > from error handler. With Xcb, which is the default now with Xlib 1.4, the > display remains locked during error handling and nested requests aren't > allowed. > > Even the older _XReply contains a comment indicating that doing requests > from an error handler wasn't considered good behavior even though it > happened to work previously: > > /* Pull out the serial number now, so that (currently illegal) requests > * generated by an error handler don't confuse us. > */ > >> The information we want is already on display->ext_procs->codes >> but "This structure is private to the library." I'm not aware of >> a public API to get this information from Xlib. >> >> I guess we could use a separate connection to query the extension >> codes. Is it reasonable to assume that all connections to the >> same display would use the same codes? > > X server seems to preserve the extension codes until the server is > regenerated and therefore all connections should use the same codes. >
Is that guaranteed by some protocol or does it just happen to work as the requests in error handler did? Thanks Michal _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
