Jamey Sharp writes: > So I don't see anything we can do except require that callers meet the > documented requirements for XSetErrorHandler. I did try to find a kludge > to let existing apps survive this bug, but anything I could think of > probably breaks multi-threaded clients.
Thanks for the follow-up. I'm happy to fix our client to avoid protocol requests on the display passed to XSetErrorHandler. (Life must be difficult for multi-threaded clients using XSetErrorHandler, but I imagine there are ways to make things work.) > On Wed, Feb 23, 2011 at 10:26:21AM +1300, xm...@karlt.net wrote: >> 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. > > Eh, that hasn't stopped anyone else who's using Xlib. :-/ > > One thing you could do if you don't want to use private APIs is to call > XListExtensions (and XQueryExtension, if you need event and error > numbers) when you open the Display. We usually try to do as little as possible on start-up. This may not take much time, but little things add up. > Otherwise, screw it, I'd just include Xlibint.h and dig out > ext_procs->codes. I feel more comfortable opening another connection. The consequences are less severe if codes ever change than if structures change. > On Fri, Mar 04, 2011 at 12:20:12PM +1300, Karl Tomlinson wrote: >> > http://lists.x.org/archives/xorg-devel/2011-February/019533.html >> > does seem to indicate another potential issue (breaking from the >> > loop only when "req == current"). I guess that hasn't bitten us >> > because we don't return to the first _XReply. >> >> That seems to have been the situation until >> http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=933aee1d5c53b0cc7d608011a29188b594c8d70b >> >> I see that we now spin even without XInitThreads. >> That is version 1.3.4 --with-xcb. > > I'm not sure what this means. Do you mean you spin due to re-entering > _XReply from _XError, or because of something involving the "req == > current" condition? Re-entering _XReply from _XError, which we'll avoid. > With the patch I just pushed, I think calling XSynchronize should once > again be safe from an error handler. Yes, that's my understanding too. That's helpful, thank you. _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel