Am 05/09/2013 00:39, schrieb John Scipione:
On Wed, Sep 4, 2013 at 12:00 PM, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote:The problem with the solution you implemented is that the ScreenSaverRunner that should run (ie. the last one clicked) might not get the lock in time, and therefore simply quits, leaving the preview non functional.Is a non-functional preview a problem you've actually experienced or are you inferring that as being a possiblity from reading the patch? I cannot reproduce that problem, and I've tried hard to bang on it to do so.
It's a race condition as there is no practical reason one thread runs before another, and there is no synchronization involved.
Just imagine the first screen saver runs on a different CPU. It manages to grab the window lock, and gets preempted by a higher priority thread. In the mean time, the now current screen saver gets to run, tries to grab the window lock, and fails to do so as the other thread still owns it. Screen savers run in low priority (and for a reason), so this isn't even just a theoretical situation.
Developers rarely get bitten by race conditions, it's always the users who have to suffer :-)
Perhaps my solution is a work-around and not a proper fix, but, it's one hell of a workaround because it transforms the screensaver app from one that stuttered and locked up easily to one that works well,
You just replaced a bad bug with a minor bug. Still a bug.Not taking the time to investigate problems but to work around them drastically worsens the code quality over time, and that both for the end user experience as well as for the developer who wants to understand it.
Bye, Axel.
