Re: [Development] QFutureInterface
Hi, Sorry for the delay. > Yes, please provide a short example with std::promise, which, afaiu, works > for your use-case. Below is a simplified example where a client calls an API function that blocks until the result is actually available. The request is sent to a queue, where a "server" thread sends a network packet to another host. As soon as the reply arrives from the network, another "server" thread uses the promise for delivering the result to the client. Thread 1 (called by client) std::promise prom; // put promise into map for later retrieval by server thread promiseMap.insert(id, prom); // trigger work queue.enqueueWork(id, workItem); // get future and block until result becomes available std::future fut = prom.get_future(); return fut.get(); Thread 2 ("server" request thread) workItem = queue.dequeueWork(); // do some work, then send the request sendRequest(workItem.id, workItem.content); Thread 3 ("server" reply thread) reply = receiveReply(); // retrieve promise for the original request std::promise prom = promiseMap.get(reply.id); // deliver result to original requestor prom.set_value(reply.value); HTH Christian ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QFutureInterface
On Friday 27 November 2015 13:45:28 Bauer, Christian wrote: > Hi Marc, > > > You should be able to develop a QPromise/QPackagedTask with the current > > QFutureInterface already. At least as long as it's attached to some > > > QThreadPool. > > What, exactly, are you trying to do that requires a patch to QFI? > > I am not aware of any QPackagedTask in Qt, only of packaged_task in C++11. > Or do you mean RunFunctionTaskBase? I said "you can develop one", not that there _is_ one already :) [...] > Our (simplified) problem is: this function does not return a value but > feeds an asynchronous pipeline. When the pipeline processing is done it > will call promise.SetResult(); promise.reportResult(); > and only then the future should be notified of the result. 1. Inherit your runnable from QRunnable and QFutureInterface In the ctor, call QFI::setRunnable(this). 2. Create an instance of your runnable, call runnable.future() to get the QFuture end 3. Schedule the runnable on a thread pool (cf. QConcurrent::run(QThreadPool* for how to implant that into the QFutureInterface so work stealing works). 4. From within runnable::run() operate the QFutureInterface API 5. Use the QFuture obtained in (2) as you'd use an other future. > We can achieve this by using a custom waitForFinished() in our future > wrapper, instead of using the QFuture waitForFinished. But this requires > access to the QWaitCondition of the QFutureInterface. Don't understand this, but maybe I don't need to. Just tell me where your use- case fails in the recipe above. Thanks, Marc -- Marc Mutz| Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QFutureInterface
Hi Marc, First: thanks for your suggestions. > 1. Inherit your runnable from QRunnable and QFutureInterface >In the ctor, call QFI::setRunnable(this). >2. Create an instance of your runnable, call runnable.future() to get the >QFuture end > 3. Schedule the runnable on a thread pool (cf. QConcurrent::run(QThreadPool* >for how to implant that into the QFutureInterface so work stealing works). > 4. From within runnable::run() operate the QFutureInterface API 5. Use >the QFuture obtained in (2) as you'd use an other future. So the QPackagedTask would be a Runnable that you run on the thread pool, and that runnable represents a QPromise at the same time. Maybe I am missing something here, but I don't think this solves my problem. In my scenario, the QPackagedTask does not produce the result. The task only triggers something else that will - in some point in the future - produce the actual result. By the time the result is produced, the original QPackagedTask does not even exist anymore. The idea of the patch is to support decoupling the Promise (QFI) from the task that I schedule via QConcurrent::run(). Some task will call the promise and set the result, instead of the promise receiving the return value of the task. I could provide a code example if this helps... Thanks Christian ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QFutureInterface
On Friday 04 December 2015 10:49:04 Bauer, Christian wrote: > I could provide a code example if this helps... Yes, please provide a short example with std::promise, which, afaiu, works for your use-case. Thanks, Marc -- Marc Mutz| Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QFutureInterface
El Friday 27 November 2015, Bauer, Christian escribió: > Our (simplified) problem is: this function does not return a value but > feeds an asynchronous pipeline. When the pipeline processing is done it > will call promise.SetResult(); promise.reportResult(); > and only then the future should be notified of the result. I would not mind see your patch in code review, and read what others have to say for or against. Having a QPromise or some other public API for QFuture would be nice, as you could attach a QFutureWatcher to it. -- Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2 http://barnacity.net/ | http://disperso.net ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QFutureInterface
Hi Marc, > You should be able to develop a QPromise/QPackagedTask with the current > QFutureInterface already. > At least as long as it's attached to some > QThreadPool. > What, exactly, are you trying to do that requires a patch to QFI? I am not aware of any QPackagedTask in Qt, only of packaged_task in C++11. Or do you mean RunFunctionTaskBase? The QFuture(Interface) represents the return value of a function, e.g., the one passed in QtConcurrent::run. The QFuture(Interface) will execute the function on a thread pool. As soon as this function returns, the return value is stored and the state of the promise set to Finished. Our (simplified) problem is: this function does not return a value but feeds an asynchronous pipeline. When the pipeline processing is done it will call promise.SetResult(); promise.reportResult(); and only then the future should be notified of the result. We can achieve this by using a custom waitForFinished() in our future wrapper, instead of using the QFuture waitForFinished. But this requires access to the QWaitCondition of the QFutureInterface. I hope the use case is clear. The C++11 future/promise achieves exactly this, and we are using the QFuture in a similar way. Thanks Christian ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QFutureInterface
Hello, There was a discussion about the "internal" class QFutureInterface a few months ago on this list [1] about making QFuture/QFutureInterface more like std::future/std::promise in C++11. It seems this is not going to happen before Qt 6. We have a use case for a promise though and the current QFutureInterface is not sufficient. A custom wrapper for the QFutureInterface solves this problem for now, but requires a patch of Qt. I am wondering if you are willing to incorporate this patch into the official Qt release. It's about adding a getter to QFutureInterfaceBase for the d pointer QWaitCondition. Such a getter already exists inside the QFutureInterfaceBase for the d pointer QMutex. Thanks Christian [1] http://lists.qt-project.org/pipermail/development/2015-July/022586.html ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QFutureInterface
Hi Christian, On Thursday 26 November 2015 11:50:10 Bauer, Christian wrote: > Hello, > > There was a discussion about the "internal" class QFutureInterface a few > months ago on this list [1] about making QFuture/QFutureInterface more > like std::future/std::promise in C++11. It seems this is not going to > happen before Qt 6. > > We have a use case for a promise though and the current QFutureInterface is > not sufficient. A custom wrapper for the QFutureInterface solves this > problem for now, but requires a patch of Qt. > > I am wondering if you are willing to incorporate this patch into the > official Qt release. It's about adding a getter to QFutureInterfaceBase > for the d pointer QWaitCondition. Such a getter already exists inside the > QFutureInterfaceBase for the d pointer QMutex. You should be able to develop a QPromise/QPackagedTask with the current QFutureInterface already. At least as long as it's attached to some QThreadPool. What, exactly, are you trying to do that requires a patch to QFI? Thanks, Marc -- Marc Mutz| Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development