>
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/dri-devel
