[Interest] QFuture, QAsync? Coroutines, Generators, Promises, Futures...

Petar Koretić petar.koretic at gmail.com
Wed Dec 28 09:36:49 CET 2016


On Wed, Dec 28, 2016 at 4:51 AM, Ben Lau <xbenlau at gmail.com> wrote:

>
>
> On 28 December 2016 at 05:50, Petar Koretić <petar.koretic at gmail.com>
> wrote:
>
>> Hi all!
>>
>> In the wild people are doing all kinds of different things with Qt on the
>> network side. And there are some obvious issues with that given the
>> "callback" nature of Qt networking code.
>>
>> One can see different examples of people over the years dealing with that:
>>
>> http://cukic.co/2016/01/17/asynqt-framework-making-qfuture-useful
>> https://github.com/KDE/kasync
>> http://qasync.henrikhedberg.com
>> https://github.com/mhogomchungu/tasks
>> https://gist.github.com/legnaleurc/1038309
>>
>> Since we are also using Qt a lot on the server side I'm curious what is
>> the progress from the Qt side on that given that coroutines will come to
>> C++ (http://en.cppreference.com/w/cpp/experimental)
>>
>> We were using Boost and as we were using Qt for clients decided we could
>> also do server parts in Qt as well. This is all fine and I enjoyed it, but
>> boost has futures, promises and coroutines as well, which is nice, since we
>> also have backends in Node.js where we employ identical patterns.
>>
>> So I've been waiting for 2 years now to see what will come up from Qt and
>> I don't see much about that changing. Heck, QAsync tackled this in 2011.
>> Will Qt "embrace" coroutines from standard? Will they come up with
>> something of their own? Should we abandon Qt for networking? Should we use
>> something of our own?
>>
>> One possible way currently is to use QtConcurrent (badly I guess) and
>> wrap everything into QtConcurrent::run, which, for example, for
>> QNetworkRequest means first converting it to sync code using local event
>> loop which is again not recommended.
>>
>>
> Why you think it is not recommended?
>
>
This was once on
http://developer.nokia.com/community/wiki/How_to_wait_synchronously_for_a_Signal_in_Qt
Local QEventloop may cause out of control recursion or deadlocks in some
cases. Whenever I had idea to use it, nobody recommended it. Quick google
search now will tell you the same.

Nevertheless, for example, QNetworkRequest is explicitly asynchronous while
QSqlDatabase is explicitly synchronous. I'm just expecting that somebody is
doing the same these days with Qt and want to improve on that given that
C++ itself will get "async" support so I want to avoid any duplication from
my side. I'm not talking about something new, just asking if there are any
plans in that direction.


> I expect that everybody is up to date and know about
>> callbacks/coroutines/futures/promises/generators these days but for
>> others here are some examples that explain it better than I can:
>>
>> http://www.boost.org/doc/libs/1_63_0/libs/coroutine2/doc/htm
>> l/coroutine2/motivation.html
>> https://msdn.microsoft.com/en-us/magazine/mt573711.aspx
>> https://blogs.msdn.microsoft.com/vcblog/2016/04/04/using-c-c
>> oroutines-to-simplify-async-uwp-code
>>
>> Thanks,
>> Petar
>>
>>
> For coroutines, any recommended implementation that is easy to be
> installed on all supported platforms by Qt?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20161228/11426f3d/attachment.html>


More information about the Interest mailing list