qpdfview team mailing list archive

[Adam Reichold <adamreichold@xxxxxxxxxxx>]

-----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-----