> > I have an application that takes the hardware DRI lock and then does an > usleep(1) while polling hardware status. Entering the polling function, I've > verified that the lock is indeed taken > 0x80000002, with 2 corresponding to the correct DRM context. Upon exit from > the polling function, sometimes the X server has stolen the lock, 0x80000001, > or even 0x1, signalling the X server already did it's processing. > The lock has never been touched by the application in-between.
Don't sleep holding the lock unless you have a good reason, the X server will take it back forcibly if it can't get it nicely as it is in charge and a locked up Xserver waiting for a client is a bad idea in terms of sharing resources.. it would be a DoS if a DRI client can just take the lock and sit on it .. take a look at the programs/Xserver/GL/dri/dri.c:DRISpinLockTimeout /* Didn't get lock, so take it. The worst that can happen is that there is some garbage written to the wrong part of the framebuffer that a refresh will repair. That's undesirable, but better than locking the server. This should be a very rare event. */ is a comment from that function.. Dave. ------------------------------------------------------- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel