https://bugs.kde.org/show_bug.cgi?id=500339
--- Comment #38 from Vartan <[email protected]> --- (In reply to John Kizer from comment #37) > I suppose the exact time mattered less than the fact that if I wait long > enough after that time - say like a full minute - then I consistently get > the password attempt responded to / don't reproduce this issue. But thanks > for sharing what's triggering it on your end then, the conditions for this > occurring must be more complex than I had assumed. The "exact time" NEVER matters where race conditions are involved (concurrency problems). The timing will NEVER be the same. It's a pointless exercise to try to reproduce by trying to debug for example in an IDE, or via println() statements in code, the latter being the absolute worst way and the least likely to be effective or informative. You have to debug this by static examination of the source code. You need to ensure that there is proper mutex locking on whatever 'object' is used to ensure exclusive access to, and atomic execution of, the code that sets the state of the screen (locked/unlocked). Of course I'm assuming in the above that the desktop environment uses proper threading idioms, and I'm assuming its written in C or C++ or leverages the libc.so mutex locking primitives. But my guess is that it's using something like the mechanisms on this page: https://www.gnu.org/software/libc/manual/html_node/ISO-C-Mutexes.html -- You are receiving this mail because: You are watching all bug changes.
