Batch Queue Manager and database lock.

[Gilles Caulier]

Maik,

Yes all work perfectly now. Elemental : creating one thread poll by
ActionThreadBase instance is the right solution. Great job.

Note : i think some file in bugzilla can be closed now with this fix,
but this wil be difficult to identify the side effect of this
dysfunction everywhere in application.

Gilles

2017-08-16 19:15 GMT+02:00 Maik Qualmann <metzpinguin at gmail.com>:
> 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
>
>