Using a mutex when threads are not involved is wrong in my book, and that's why my branch uses a bool as customary

Do you suggest I should write my own bool-based RAII wrapper, which would be racy, less efficient, buggy, more verbose and harder to read? Using a mutex solves the maintainability risk outlined in D7495#141032 with no costs. Also, when researching this, I got the impression that a mutex is more customary when locking is involved (which is what we are doing here).

I don't suggest you write anything, there's aleady code that works in my patch and it's really much easier to understand what it does than this one.

I guess someone else should judge which is easier to read considering the full picture (I got confused by your areWeReloading naming, actually). I admit someone not familiar with std::mutex semantics would need to read the comment, but understanding a custom RAII wrapper is even harder.

Could you suggest another reviewer?

From merely looking at the patches, I like this one better than Albert's. In Albert's patch, the fact that you have to set m_areWeReloading at every exit of the method slotDoFileDirty does feel like breakage waiting to happen.

On the other hand, Albert's objection "Using a mutex when threads are not involved is wrong in my book" is not without reason either. Casual readers of the code will see the mutex and expect there to be threading. I therefore suggest to expand the comment in part.cpp:1773 to clearly state why the mutex is needed, and why it does not have anything to do with threading.

Is that a reasonable compromise?

To be honest, I liked your first patch better. Granted, that definition of reloadLock is elegant, but you need quite a bit of C++ experience to see its beauty. People without that will be scared.

But it is really Albert who decides.

Please abandon this revision, i commited https://commits.kde.org/okular/a6aea956081e8faac2484ab2283a5ab50f9e0bbe