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