@SimonSchroeder said in Continuation not working with QtConcurrent::mapped:
What we have figured out so far is that mapped() returns a future. The second mapped (if it somehow would work) would wait for the full future to complete.
Why? That would be up to the implementation. It could track individual results (if there are many), and start those that can start.
Also remember that thread communication/synchronization has heavy overhead. If you chain two different mapped calls together you will have this overhead twice. This means it is quite sensible to put the two function calls into a single mapped call. I can't think of anything in the STL to merge two function calls to be passed as a new function pointer. You could come up with something like this (untested!):
Overhead, sure. It's my responsibility to only start work this way where it makes sense to move it to separate threads. My example is certainly not a good candiate :-)
In general, I wouldn't mind if ".then" on a "mapped" future simply wouldn't compile (best), or the behavior was documented and I got a runtime error (also ok). That is silently drops everything but the first result is "unexpected behavior".
I wonder about the design decision to make a QFuture both a single value AND a container...but I guess, that ship sailed long ago.