On 02/01/2018 02:31 PM, Adam Jackson wrote:
On Wed, 2018-01-10 at 13:57 -0700, Kyle Brenneman wrote:
xorgGlxThunkRequest should be calling addXIDMap and removeXIDMap, not
the internal handlers.
I'm not sure that can be right. If it did, and adding the map failed,
there's no way to get the backend to clean up; at least, not the way
GlxAddXIDMap is currently written. Perhaps that should be changed to
call FreeResource on the XID if AddResource fails? (Like the one place
in the whole server where that'd be correct...)
It works if the stub calls addXIDMap first, before calling into the
vendor. Then, if addXIDMap fails, then the stub can return BadAlloc
before the vendor has a chance to do anything that would require cleanup.
If the vendor returns an error code, then the stub would call
removeXIDMap to clean up before returning.
That's also why the LEGAL_NEW_RESOURCE call has to be moved to the
dispatch stub: The addXIDMap call happens before calling into the
vendor, so by the time the vendor gets called, there's a resource
defined for that XID and LEGAL_NEW_RESOURCE would fail.
The default branch there may need some additional
attention if it would handle any requests that create or destroy resources.
It would. The only other vendorpriv extension I know of that does that
is the underspecified and probably unimplementable
GLX_SGIX_video_source though, so it's not really a big deal.
- ajax
_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
