[PATCH xlib] Add support for a display-specific error handler
Jasper St. Pierre
jstpierre at mecheye.net
Mon Nov 16 09:06:03 PST 2015
Yes, because Xlib will pick those events up and call its default
handler in its mainloop. As far as I can tell, there's no way to
configure that behavior. Using xcb without the Xlib mainloop is not an
option, because this is a library embedded in another application and
its API takes an Xlib Display* (also because it's a nearly 10,000 line
codebase and porting it to xcb in one giant go is not fun, especially
when xcb code is some of the least fun code to write in the universe).
We currently use a behavior like:
SetErrorHandler();
Request1();
Request2();
Request3();
if (UnsetErrorHandlerAndCheck())
goto error;
UnsetErrorHandlerAndCheck will XSync, and look at any newly incoming
errors, check their serials so that they match up, and if they are
inside those bounds, we return the error to the user and return that
no error happened. Fairly standard trick.
With xcb, I can do:
if (check_request(request_1_checked(), &err) {
free(err);
goto error;
}
if (check_request(request_2_checked(), &err) {
free(err);
goto error;
}
if (check_request(request_3_checked(), &err) {
free(err);
goto error;
}
But this quickly becomes obnoxious (and requires an XSync/wait on
every request) As far as I can tell, I can't pick up *only* error
events, meaning that if during that time I make those requests, there
are other events in the queue, I can't filter through the queue for
any errors that might have happened. If I have any events, I have to
handle all of them.
So that's clearly unusable.
The Display-specific error handler solves my needs here by giving me a
callback to that above model that's locked to that local section that
works well from a library -- this code runs in a different thread, and
we had issues where we overwrite another thread's error handler (in my
case, the two threads were using different Displays, as they should).
On Sun, Nov 15, 2015 at 11:56 PM, Keith Packard <keithp at keithp.com> wrote:
> "Jasper St. Pierre" <jstpierre at mecheye.net> writes:
>
>> Writing error-safe code that uses Xlib is too obnoxious, and using XCB
>> is tedious and not performant, as we can't catch events on a giant
>> stream -- we have to check every operation manually.
>
> You get errors returned in the event stream; is there something fancier
> you'd like from xcb to make it faster?
>
> --
> -keith
>
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
--
Jasper
More information about the xorg-devel
mailing list