Hi! I'm currently looking into the thread-safety of the dri drivers. In particular the calls to libX11.
It appears that many of the applications I've tried have issues with deadlocks in the XCB code. It looks like this might be an issue with the locking order of XLockDisplay() and driver mutexes. In particular, if the application protects all glx calls with XLockDisplay() the driver might deadlock in a normal GL call: Thread A: XLockDisplay() -> glxXXX -> driver mutex -> Xlib call -> Xcb XLockdisplay(). Thread B Normal GL call -> driver mutex -> Xlib call -> Xcb XLockDisplay(). So we have a locking order reversal between the driver mutex and XLockDisplay which causes a deadlock. Now, it seems like a simple away around this would be to omit the application XLockDisplays() completely. However, that seems to cause issues with XPending and XNextEvent eating the reply data meant for XSync(), leaving XSync waiting locked in a select(). I guess the remedy is to have the DRI utility routines and drivers protect _all_ X calls with XLockDisplay(). Does anyone have thoughts / insights about this? Thanks, Thomas ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
