-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello,
Because I was asked to do explain this in a bit more detail, I'll try: On 24.07.2012 19:20, Adam Reichold wrote: > Hello, > > Something unpleasant happened: Someone testing the current trunk > revisions reported reproducible race conditions in the current > rendering code when prefetching is enabled. After some > consideration, I redid almost all threading involved and changed it > to a more robust signals-based design. (The alternative was to > remove prefetching.) Race conditions in this case means, that pages were not rendered because prefetching was canceled... But prefetching is not supposed to be cancellable... (By design, so to speak.) But if prefetching finishes, and a new rendering starts before the results of prefetching are dispatched and the rendering is canceled, then the result of a canceled rendering - an invalid empty image - is stored in the cache as a (supposedly valid) prefetching result. So the problem is that the correct functioning depends on the ordering of operations performed in different threads which are executed in parallel. Usually, this should not happen as the programmer should have taken care to avoid such ordering dependencies via locking or similar mechanisms. If not done correctly, the threads sometimes "race" to fulfil some strange condition that leads to incorrect function... In this case, I used a simple lock-less design utilizing that QImages are actually atomic pointers to implicitly shared data, but my state handling got completely screwed by introducing prefetching and after fixing the memory management bug Sandor reported, it got even more complicated. So I more or less redid it. Not depending on a lock-less design but letting Qt signals and slots handle the passing of data between threads. This could lead to a higher memory usage if not done correctly. Hopefully I did not screw up this time. Practically, this meant that some pages were just not rendered if prefetching was enabled and the scrolling was timed correctly. (Rather hard to reproduce, but possible.) They were rendered after zooming in or out and if they were actually visible, i.e. when prefetching was not involved. Currently, after the latest changes, everything should be fine and working as expected with a simpler code base. But it is just so late in the development cycle that I chose to issue a third beta of version 0.3.2. Hence the need to test for rendering and memory management problems. Especially with respect to the different view modes like continuous and also the presentation view. > This should improve the robustness of rendering resp. threading, > but this close to releasing version 0.3.2, I am very uncomfortable > with such a intrusive change. So if you have some spare time on > your hands, please test any version newer than trunk revision 476 > concerning rendering, prefetching and - connected to that - memory > consumption. > > Thank you for your help! Best regards, Adam. > Best regards, Adam. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQDvC5AAoJEPSSjE3STU34WKgIAIr4MJiwRYhDJyswt6vzG9/I 3eeUKIBjlM/ScfRfxnxH2mbRLwwbhPodzMDnUvfcnJUXeFVnxRbDPQS3jWGmspIg E62QOzhZzm2jcvzhqQ7jVAzTBP0Y6NDKN09eDPCGNrR4YP0X+R34lX7pdN4yNlO/ clOFFh+t130bD4zKAvx1fED0RIym8+vGocgqTLU8DFxRp9fimgfIodfJQmFcP313 hqnqcAs5tk1gvyL9LtQPxIN2WnV9Rd9XRybtzFEJoumV5E4ymMLcKq+CQNbOiH4L kVK2J+e0c+r9Xq/verRfGkfrxg/tuLAL5K42zmlAjxnGAqkO5dLiMTsNyhSJv0M= =VAnD -----END PGP SIGNATURE----- -- Mailing list: https://launchpad.net/~qpdfview Post to : [email protected] Unsubscribe : https://launchpad.net/~qpdfview More help : https://help.launchpad.net/ListHelp
