<div dir="ltr"><div dir="ltr">With this commit : </div><div dir="ltr"><br></div><div dir="ltr"><a href="https://commits.kde.org/digikam/134d5731cdc5f0e99df3839f943bd60804e96072">https://commits.kde.org/digikam/134d5731cdc5f0e99df3839f943bd60804e96072</a></div><div dir="ltr"><br></div><div>I introduced the first stage to consolidate metadata extraction with Exiv2 using multi-threading.</div><div><br></div><div>Gilles Caulier</div></div><br><div class="gmail_quote"><div dir="ltr">Le jeu. 8 nov. 2018 à 09:22, Gilles Caulier <<a href="mailto:caulier.gilles@gmail.com">caulier.gilles@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi all,</div><div><br></div><div>With this commit :</div><div><br></div><div dir="ltr"><a href="https://commits.kde.org/digikam/1b434ace96e4bec1392ae14800e1fbb8a5bb6071" target="_blank">https://commits.kde.org/digikam/1b434ace96e4bec1392ae14800e1fbb8a5bb6071</a><br></div><div dir="ltr"><br></div><div>The unit test settings can be customized to perform a check over a local collection. I would to know if crash can be reproducibled when metadata are read from files in other computer.</div><div><br></div><div>Best</div><div><br></div><div>Gilles Caulier</div></div><br><div class="gmail_quote"><div dir="ltr">Le jeu. 8 nov. 2018 à 00:18, Gilles Caulier <<a href="mailto:caulier.gilles@gmail.com" target="_blank">caulier.gilles@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr">Another second big problem with Exiv2 is the memory allocation of DMetadata before to use, especially with large files to parse (depending of file mime types).<div><br></div><div>DMetadata (and in fact the internal Exiv2 objects) need to be allocated on heap, not on stack. Similar problem was discovered by Maik with last libraw 0.19 objects.</div><div><br></div><div>So the DMetadata wrapper need to use QScopedPointer. See my code from this unit test function :</div><div><br></div><div><a href="https://cgit.kde.org/digikam.git/tree/core/tests/metadataengine/metareaderthreadtest.cpp#n60" target="_blank">https://cgit.kde.org/digikam.git/tree/core/tests/metadataengine/metareaderthreadtest.cpp#n60</a><br></div><div><br></div><div>Gilles Caulier</div></div></div><br><div class="gmail_quote"><div dir="ltr">Le mer. 7 nov. 2018 à 23:41, Gilles Caulier <<a href="mailto:caulier.gilles@gmail.com" target="_blank">caulier.gilles@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>Actually, i write and test with unit-tests, over Exiv2 and metadata extraction.</div><div><br></div><div>In DK, the metadata wrapper over Exiv2 is based on MetaEngine and the inherited class DMetadata. All my tests use DMetadata which provide the most complete API to play with information.</div><div><br></div><div>I already found few internal problems, and with the help of Maik, we fix all this stuff.</div><div><br></div><div>But the last unit test to finalize, is the most problematic : the stress access to Exiv2, with muti-cores and multi-threads.</div><div><br></div><div>Typically, i setup a manager which scan a huge collection of files (40.000 JPEG, PNG, TIFF, RAW, Video, etc.). Each file is read from separated thread to catch most important informations (the famous ones stored in database). Here, 8 cores are used, and 32Gb of ram permit to eliminate all memory leak side effects.</div><div><br></div><div>The unit test do not play with database, but stress only Exiv2. It's enough and in fact show quickly the Exiv2 limitations :</div><div><br></div><div>- Exiv2 API are not re-entrant. </div><div>- This is not only limited to files parser. </div><div><br></div><div>In digiKam, all is multi-threaded, especially the database scanners, and the maintenance jobs. The threads running Exiv2 API can crash suddenly and let's the application in pending states for a while. Depending of the context in memory, the application can crash or not, but in all cases, the threads management is broken and application will not responding.</div><div><br></div><div>The only solution in whole digiKam implementation is to wrap all calls to DMetadata to a thread-safe interface using Mutex Locker. This will reduce the performances, but gain for stability is incredible.</div><div><br></div><div>Best</div><div><br></div><div>Gilles Caulier</div><div><br></div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>