QFutureWatcher::setPendingResultsLimit does not appear to “throttle” execution of the future it is attached to

  • I have a QFuture that may fire tens or hundreds of results in very short burst and I wish to read each of these results and process them as they are finished.

    QFutureWatcher should allow this through their void QFutureWatcher::setPendingResultsLimit(int limit) function. The QFutureWatcher::setPendingResultsLimit(int) says

    The setPendingResultsLimit() provides throttling control. When the
    number of pending resultReadyAt() or resultsReadyAt() signals exceeds
    the limit, the computation represented by the future will be throttled
    automatically. The computation will resume once the number of pending
    signals drops below the limit.

    What I understand from this is execution will be blocked once this limit is reached. i.e. If I have the following example:

    // Create watcher & future somewhere in header file
    QFutureWatcher<int> watcher;
    QFuture<int> squareFuture;
    int max = 100; 
    int limit = 10;
    // scale number function used in mapping
    int squareNumber(int i) {
        qDebug() << "Processing: " << i;
        return i*i;
    // implementation (on a button click)
    QList<int> list;
    for (int i = 0; i < max; i++) { 
    // start future (square number here is a static function with the signature `int(*)(int)`
    squareFuture = QtConcurrent::mapped(list, squareNumber);
    // connect listeners (add future connections before setting future to "prevent race condition" - qt docs)
    connect(&watcher, &QFutureWatcher<int>::started, this, [](){
        qDebug() << "Future started";
    connect(&watcher, &QFutureWatcher<int>::finished, this, [](){
        qDebug() << "Future finished";
    // set future
    // set future max results

    This will create & run the future with a watcher attached listening for a start & finished and setting the number of results to 10 (in which case, I will have to 'clear' the pending results 10 times to finish - assuming the limit is 100).

    If this above is correct, then my code (which can be describe as the example above) does infact NOT limit/block execution. It outputs "Future Started", the processed numbers then "Future Finished"

    Future started
    Processing:  0
    Processing:  1
    Processing:  2
    Processing:  3
    Processing:  4
    Processing:  5
    Processing:  6
    Processing:  7
    Processing:  8
    Processing:  9
    Processing:  10
    Processing:  11
    Processing:  12
    Processing:  13
    Processing:  14
    Processing:  15
    Processing:  16
    Processing:  17
    Processing:  19
    Processing:  18
    Processing:  20
    Processing:  21
    Processing:  24
    Processing:  22
    Processing:  25
    Processing:  23
    Processing:  27
    Processing:  26
    Processing:  28
    Processing:  29
    Processing:  31
    Processing:  36
    Processing:  32
    Processing:  93
    Processing:  90
    Processing:  94
    Processing:  91
    Processing:  95
    Processing:  96
    Processing:  97
    Processing:  98
    Processing:  99
    Future finished

    Did I miss something or misunderstand what is meant by "throttling" as infact blocking execution, also what constitutes as "the number of pending signals drops below the limit", as a sub question: how do I reduce the number of pending results

    Note: I can provide my code - but this is a narrowed down version of mine, where the entries number is much smaller, mine is 50000000 (for testing purposes)

  • Lifetime Qt Champion

    I would guess your computation is just to fast. Also the documentation does not say anything about the started/finished signals, only about result/resultsReadyAt()

  • @Christian-Ehrlicher

    Thanks for the response but the fault is actually on my side.

    I had another QFutureWatcher named...well... futureWatcher when I was testing something else. I assigned the future to this QFutureWatcher which is why the limit was never reached.

    It should infact be: watcher.setPendingResultsLimit(limit) which works perfectly.

    Another prime example of PEBKAK

Log in to reply