Batch Queue Manager and database lock.

Maik Qualmann metzpinguin at gmail.com
Sun Aug 13 11:26:44 BST 2017


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



More information about the Digikam-devel mailing list