Hi wysota,

Thanks for joining in and for helping me finding some solution to my issue ;-)

I don't think you can do that in a general case. If you want to try, install a QFutureWatcher on the future returned by the mappedReduced() call. If the future returned represents a list (which I doubt - that's why I say I don't think it is possible to obtain what you want), you would then be signalled when particular results are ready.
Actually, I do use a GFutureWatcher. The result of my 'mappedReduced()' function was a large vector, but I did not manage to get access to it before the whole thing was processed. Besides, The 'resultReadyAt()' signal was never triggered... except at the end. I think this nice method is just not expected to be used as I wanted to use it.


I can think of some things that could be used. For example you could process the data in chunks - divide the whole domain into subdomains, process one subdomain using Qt Concurrent, then partially reduce the result, free the memory and proceed with the next subdomain. Instead of a flat line of parallel execution you'd get a kind of a tree of executions.
I see your point. But wouldn't that add a lot of overhead, to start new QtConcurrent instances over and over? I thought this is a quite "expensive" action to do, and I might then lose the benefit of multithreading with QtConcurrent, or ?...


Another solution I can think of is to leave mapped() and use QRunnable objects to process each chunk of data. When a particular runnable is finished, you can process its result in the main thread and get rid of the runnable right away.
I have thought about this way too, using a ThreadPool, and at the end, this might be the most flexible and powerful way way after all, but I did not try it out yet.
'mapped' and 'mappedReduced' are so convenient to use, because they handle automatically and efficiently the available CPU cores.
I would like to investigate a bit further the 'mapped' alternative, and if can find an elegant way to solve the memory usage problem.
If I don't succeed, I'll probably redesign the whole stuff around Thread Pools...


Thsnk again for the suggestions.

I'll feed this thread with my further outcomes, since it might interest other folks too, and there are not so many info available yet on the forums in general about QtConcurrent usage.


Kind regards,


0x4e84