Thoughts, yes, but this was a situation in which a company sponsored the work in order to fix a specific application issue. There was a limited budget, so I was attempting to solve the problem in the most expedient way possible.
I also didn't want to introduce a dynamic loading mechanism because VGL 2.4 is already in beta. Thus, this feature needs to remain isolated for the moment in order to avoid regression. I would be interested in introducing that mechanism in 2.5, however. I am definitely also interested in fixing the deadlock. Please post both patches to the patch tracker. > On Nov 20, 2014, at 5:28 PM, Nathan Kidd <nathan...@spicycrypto.ca> 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
