Spinning in _XReply
xmail at karlt.net
Tue Mar 15 18:40:01 PDT 2011
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, xmail at 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
I feel more comfortable opening another connection. The
consequences are less severe if codes ever change than if
> 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
>> 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.
More information about the xorg-devel