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

Thu, 29 Dec 2016 08:27:29 -0800

I've been looking into this recently, and the industry is converting on async/await keywords.
They (and generators, coroutines, etc) are in ECMAScript 7 (babel supported), Python 3.5 (with complete support in 3.6) I consider generators as an incremental step to async/await
 
JS:
async function () {
     await someOtherAsyncFunction();
}
 
Python:
async def ():
     await someOtherAsyncFunction()
 
The draft you mention is far from complete, but it suggests a similar syntax but prefixed with co_*
 
My bigger opinion of these things is that while they increase single-threaded performance, they are really are in the wrong direction. We're headed to more cores, so eeking-out the last little bit of your timeslice is still admirable, but is an artificial limitation imposed by single-threaded environments. The real focus should be on more computing core indepenence, which is what QtConcurrent gives you. The only single core computer I own is a $5 Raspberry Pi Zero. The most recent Pi is now a quad-core. A 7-year old cellpone, the Motorola Atrix, was the first dual core phone. The _only_ place where single-thread async computing makes sense is io-bound processes. In all other cases the lack of proper threading works against you. JS evidences this because it's event loop is blocked for long-running processes, which delays the scheduling of other events on the loop which causes a scheduling cascade, which create "slow" or "janky" Browser UIs.
 
That being said, my single-thread async web server services over 1000 real, non-cached requests a second. But all it's doing is processing incoming JSON and serializing to a database, or the reverse.  
 
Sent: Tuesday, December 27, 2016 at 4:50 PM
From: "Petar Koretić" <petar.kore...@gmail.com>
To: "Qt Project MailingList" <interest@qt-project.org>
Subject: [Interest] QFuture, QAsync? Coroutines, Generators, Promises, Futures...
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:
 
 
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.
 
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:
 
 
Thanks,
Petar
 
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Reply via email to