Re: [Development] QFutureInterface

2015-12-11 Thread Bauer, Christian
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

2015-12-04 Thread Marc Mutz
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

2015-12-04 Thread Bauer, Christian
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

2015-12-04 Thread Marc Mutz
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

2015-12-03 Thread Alejandro Exojo
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

2015-11-27 Thread Bauer, Christian
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

2015-11-26 Thread Bauer, Christian
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

2015-11-26 Thread Marc Mutz
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