https://bugs.kde.org/show_bug.cgi?id=425971

b...@mogwai.be changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
      Latest Commit|                            |https://invent.kde.org/grap
                   |                            |hics/gwenview/commit/d15622
                   |                            |e1655ba7fcd33479f9677112340
                   |                            |b2de7ff
             Status|ASSIGNED                    |RESOLVED

--- Comment #10 from b...@mogwai.be ---
Git commit d15622e1655ba7fcd33479f9677112340b2de7ff by Bart De Vries.
Committed on 26/09/2020 at 13:11.
Pushed by ngraham into branch 'release/20.08'.

Fix deadlock when closing gwenview importer

When gwenview_importer is closed after importing files, it gets into a
deadlock.  This bug was introduced in commit 4f7d35d1 by the refactoring
of thumbnailprovider and thumbnailgenerator.

The deadlock is caused by the fact that closing the application will
directly trigger a wait() in the thumbnailgenerator thread which will
wait on proper closure of this thread before allowing the application to
exit.  However, this thumbnailgenerator thread is, at that moment, in a
QWaitCondition state which is intended to wait on new thumbnails to be
generated.
As far as I can see, this is not a problem in the main gwenview
application because the deadlock will eventually be lifted by the
destruction of the thumbnailgenerator object by the chain of destructors
going from application level down to thumbnailprovider which is the
owner of this object.
In the importer the situation is a bit different.  After importing has
finished, the thumbnailpage which is the owner of thumbnailprovider
is not the current widget anymore.  It still exists in the background in
case the user presses the "Import more Documents" button.  For some
reason the destruction chain doesn't seem to properly trigger the
cancel() function of the thumbnailgenerator object/thread.

The simple solution is to call the cancel() function just before the
wait() function is called when the application emits aboutToQuit().
This is proper behavior, since the thumbnailgenerator should always be
triggered to close down when the application is quitting.

M  +1    -0    lib/thumbnailprovider/thumbnailgenerator.cpp

https://invent.kde.org/graphics/gwenview/commit/d15622e1655ba7fcd33479f9677112340b2de7ff

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to