On Thu, Dec 29, 2016 at 5:26 PM, Jason H <jh...@gmx.com> wrote: > 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() > >
This is exactly what we use in Node.js, latest ECMAScript7 using babel, we have kickstart here if anyone find it interesting https://github.com/qaap/node-kickstart > 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. > Yea, I do agree, but we are trying to make a framework that is friendly out of the box, which still allows finer approaches, and threading is not simple. > *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: > > 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. > > 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/ > html/coroutine2/motivation.html > https://msdn.microsoft.com/en-us/magazine/mt573711.aspx > https://blogs.msdn.microsoft.com/vcblog/2016/04/04/using-c- > coroutines-to-simplify-async-uwp-code > > 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