I reproduced the deadlock using my build of Qt 5.3.1 on RHEL 6 and checked in a patch to trunk that addresses the issue, but I'm still tripping up on exactly how that deadlock is occurring. Qt5 doesn't ever call XPending(). It uses the XCB event handling functions directly.
On 11/20/14 5:28 PM, Nathan Kidd wrote: > A couple quick and rough notes: > > > 1. Deadlock > > I was recently playing with the new XCB support for QT5 and found an issue. > > The current xcb event handler tries to query an atom on the same > connection the event was polled from. > > Modern libX11 (at least what was on my Ubuntu 14.04 box) implements > XPending like: > > lock connection > xcb_poll_event_etc. > vgl event handler tries to query atom which attempts to get the > connection mutex, deadlocks. > > How I repoed: > - run fluxbox or Unity (probably any WM would do) > - run the QT5 hellogl example app > - click on the GL window > > I worked around this by querying the relevant atoms at XOpenDisplay time > (storing them along with the xcb_connection_t* -> Display * hash map). > > I don't attach a patch because I'd backported the XCB code to my > pre-refactor-everything 2.3.4 branch and made the patch there. > > If interested I can post it. Otherwise I'll try and get time to make a > patch for trunk eventually, if I'm not beaten to it. > > 2. Dynamic (link) XCB support > > I really hated the idea of shipping two versions of the gl faker. (One > with XCB support, one without), so I implemented XCB support > dynamically, so it can build and run on e.g. RHEL5 or earlier. (RHEL5 > can yum install xcb libs, but they aren't installed by default, in my > observation, and I don't want to break existing installations) > > If interested I can post that patch also. Ideally this would wait to > load the xcb libs till it sees an xcb symbol that needs faking used. > Unfortunately we need the xcb_connection_t->Display hash map built from > the beginning so for now I'm unconditionally loading the xcb symbols > into the app symbol namespace. Hmmm, I suppose that could be worked > around by building a Display hash list that's used to generate the xcb > conn hash on first xcb use. > > I'm curious if you had any thoughts on this when you implemented. > > > -Nathan > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk > _______________________________________________ > VirtualGL-Devel mailing list > VirtualGL-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/virtualgl-devel > ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk _______________________________________________ VirtualGL-Devel mailing list VirtualGL-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
