qpdfview team mailing list archive

[Benjamin Eltzner <b.eltzner@xxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi everybody,

as I was the one to find the bug in the first place, I did some quite
extensive testing with Adam today and in the current trunk revision
prefetching seems to work just fine for me. I tested with a standard
latex output file without images and with a very large file consisting
almost exclusively of images, and so far no problems have occured.
Memory usage also seems to be fine. I tried some different display sizes
and the presentation view. Still it would be great, if some of you could
do some additional testing, to be sure.

Best Regards,

Benjamin


> 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 v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQECSDAAoJEK27BRz67lmp1qEP/1oDEOaBcqGDoRRCm60waqnF
0WeZ6tjS8VxH2RWnVBcSFRfTI9Czz1hw9d5k5LohBs6ZmkwGOunYg0djwb8g9uK6
wxw8yEnInGJCZCZ+G4RKv/hkMNMAr6tfrzCOPTzZZUjszD0lfqjISQb7Siwzh0uq
2gzAP6nKi//be4ZeKs8hmo4T4qwV05QuVyv5MSVKRtdk6wW/0FkX8ALWFbC0hxZM
+dSCjg68zzsPYkq4VUBqVJeCVlKKG4VNQJfJ2m3ft0tRZx52idZuGguM0A7F6pEQ
ssMjdyOBUrccATRjaHKh3ZwCVSebY4fZSoqly6KjQD3sf8MblWjP1T5+kSJf/AhB
c7YSdxwUYRCAHSCr/bhkAZzY21AsQ/8wKU1m7SE/XifzoooNcJMIOPUBZc7rPTK5
PMd8M1jDf6YbkPdgQpQ5PraQoLP0wZBmwzY0FtNni0TbJWA5xuFCqfH8XG8yhOc7
42I1FEZz4W9KJ5Ud+MWaTIhznwwv53zdW/DLpH1VdA7V/cEFiXz/+r1FJHkdwMUt
zwxle/H4/WdIILi6vrl0L5sDGj56iG2ItxFfT1AMtFWJGPkX7ghmolj3ocesYV3D
dU1XdN3NufWvmDn0DAhvVumOVZ8+KLUtK5Y0GoGEpGTCSyO4ZLGJ0cJgPgr+rdrk
vcs4eQ1UKaTEUqW//kOM
=DPzN
-----END PGP SIGNATURE-----