Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-61928

Make a decision for asynchronous APIs

    Details

    • Type: Bug
    • Status: Open
    • Priority: P3: Somewhat important
    • Resolution: Unresolved
    • Affects Version/s: 5.9.1
    • Fix Version/s: None
    • Component/s: Core: Threads
    • Labels:
      None

      Description

      We all understand and know that it's hard to make a decision on asynchronous APIs.

      But when we are honest, QFuture is a amazingly good shot in the right direction. But it ain't finished: you can't reset a QFutureInterface instance back to its initial state, after having reported it is finished. Also isn't QFutureInterface public documented. Also is its API claimed not to be official. This casts doubt at many of the companies I do freelance work for. And this makes people think in a varied way about it. This makes the type a "difficult sell". I understand the doubts about it. But I don't understand the many years that Qt is keeping it hostage.

      I saw a mailinglist thread about bringing KJob to a QJob or a QAbstractJob. Because, of course, KJob can't be blocking. Because KJob has interactive questions while the job is ongoing (do you want to overwrite this file, yes or not?). I get this. But in itself, it's no reason to indefinitely block QFuture. Can we improve QFuture's API for such a QJob? Or can we extract common API out of QFuture and QJob and make a new type that both share? Anything is better than the current stalemate.

      As a developer I feel like being blocked by you guys. I want to explain to my customers to use a good return type for asynchronous operations. But rightfully my customers are replying: well look, the Qt guys themselves have no fscking clue what to do here. How are we supposed to have a clue, then?

      They are right. Please, guys, get a fucking clue on this. And sorry for my language.

        Attachments

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            People

            • Assignee:
              mmutz Marc Mutz
              Reporter:
              pvanhoof Philip Van Hoof
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:

                Gerrit Reviews

                There are no open Gerrit changes