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

[Petar Koretić]

On Sat, Dec 31, 2016 at 2:40 PM, Vlad Stelmahovsky <
vladstelmahovsky at gmail.com> wrote:

>
> All this discussion sounds like a bad joke: lets bring worse solutions
> from worse environment, where the solution reinvented the wheel to hide
> solution's poor design workaround
> If you are not satisfied with current's Qt proposals (QThread,
> QThreadPool, QConcurrent, QFuture, QEventLoop etc), probably you did wrong
> platform choose for your mindset
>

Please don't. No use in hindering discussions with useless comments. This
kind of comments were once against modules in C++. Now look what that
brought up.
This is what is coming in C++, language that you probably write if you use
Qt http://en.cppreference.com/w/cpp/experimental

It's important to see what Qt is doing, Wrapping blocking api in a thread
is not the same as using api that is non blocking in the first place. It
may end up being the same but it is definitely not by default. Hence the
difference between QNetworkRequest (nonblocking API) and QSqlDatabase
(blocking API).

br
> Vlad
>
> On Sat, Dec 31, 2016 at 2:10 PM, Ben Lau <xbenlau at gmail.com> wrote:
>
>>
>>
>> On 28 December 2016 at 16:36, Petar Koretić <petar.koretic at gmail.com>
>> wrote:
>>
>>>
>>>
>>> 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/com
>>> munity/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 think a topic is not well discussed do not mean it is not recommended.
>> I am using QtConcurrent for handling asynchronous task. So far I have
>> encountered deadlock issue only once. It happen when the application quit
>> but the task is not finished yet.
>>
>> Coroutine should be a good solution for many problems. I may switch to
>> coroutine if the task is not CPU intensive.  But unfortunately that it is
>> not available in Qt yet. So user need an alternative solution. It can't
>> just wait for new version of Qt. QtConcurrent may not be a bad choice. It
>> should be worth to discuss.
>>
>> I am not sure is any Qt developer working on coroutine yet. I think it is
>> better to ask in developer mailing list.
>>
>>
>> _______________________________________________
>> Interest mailing list
>> Interest at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>>
>>
>
>
> --
> Best regards,
> Vlad
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20170101/22be1e23/attachment.html>