Batch Queue Manager and database lock.

[Maik Qualmann]

Gilles,

please test the last commit. DigiKam hast almost better reaction also in the 
maintenance tool. ((:-))

Maik

Am Sonntag, 13. August 2017, 12:51:35 CEST schrieb Gilles Caulier:
> I just tested your patch, and this do not solve the problem.
> 
> I add 100 files to rotate and unsharp to BQM (JPEG) and run with one
> coreto use. I go back to album view and try to naviguate between
> album. All still empty until BQM has completed one task in progress.
> In this case, the selected album appear. BQM continue in background.
> If i switch to another album, the icon view is empty... until next BQM
> task is complete.
> 
> I see in you patch that you tune job collection item priority to
> process. Take a care to not confuse "priority of thread and priority
> to process a thread. If i remember the priority here is the delay to
> process a thread in the QThreadPool (a delay in ms before to process
> the job). I'm not 100%% sure, but look to QThreadPool::start() API
> details.
> 
> Gilles
> 
> 2017-08-13 12:26 GMT+02:00 Maik Qualmann <metzpinguin at gmail.com>:
> > Gilles,
> > 
> > Yes, you are right with the memory usage in the BQM at multicore.
> > Compiling is now fixed. QThreadPool is global, we should not limit the
> > number of possible threads. However, with single core option, always
> > start only new job when the other is finished.
> > 
> > Maik
> > 
> > Am Sonntag, 13. August 2017, 12:09:57 CEST schrieb Gilles Caulier:
> >> 2017-08-13 8:40 GMT+02:00 Maik Qualmann <metzpinguin at gmail.com>:
> >> > Yes, the number of threads we use applies to all instances. We should
> >> > always use all CPU cores. In BQM it makes no sense to limit it to a CPU
> >> > core. Where was the problem in the maintenance tool?
> >> 
> >> Your patches do not compile with Qt 5.6 LTS:
> >> 
> >> [ 39%] Building CXX object
> >> core/libs/threads/CMakeFiles/dthread_src.dir/actionthreadbase.cpp.o
> >> /mnt/data/GIT/5.x/core/libs/threads/actionthreadbase.cpp: In member
> >> function ‘void Digikam::ActionThreadBase::cancel()’:
> >> /mnt/data/GIT/5.x/core/libs/threads/actionthreadbase.cpp:177:18:
> >> error: ‘class QThreadPool’ has no member named ‘tryTake’
> >> 
> >>         d->pool->tryTake(job);
> >>         
> >>                  ^
> >> 
> >> core/libs/threads/CMakeFiles/dthread_src.dir/build.make:62: recipe for
> >> target 'core/libs/threads/CMakeFiles/dthread_src.dir/action
> >> threadbase.cpp.o' failed
> >> 
> >> Using one CPU core make a sence everywhere. in BQM, if you use
> >> multicore (8 for ex on my host computer) you will run 8 BQM task at
> >> the same time. The memory allocation can be huge, depending of image
> >> sizes to process. If all memory is allocated, DK will crash.
> >> 
> >> There is an entry in bugzilla if i remember, to be more intelligent
> >> with cpu cores to handle, depending of system resources available.
> >> 
> >> The problem is exactly the same with Maintenance tools.
> >> 
> >> and also, the problem is more critical with 32 bits OS where memory
> >> avaialble is limited to 4Gb, where 1Gb is typically already reserved
> >> for the OS.
> >> 
> >> Gilles