AFAIK, nesting event loops should be used with a great carefulness and in very limited set of cases, since it may break the expected order of event handling, i.e. when used as a signal waiter. Dunno if this changed since Qt 4.x, though.
Regards, Konstantin 2013/9/12 André Somers <an...@familiesomers.nl> > Op 11-9-2013 17:19, David Faure schreef: > >> Couldn't such a class be part of the hopefully coming QtConcurrent > >> replacement? > > Can we forget about threads for a second? > No, I'd rather not forget that huge pink elephant in the room... In this > age of multi-core systems being the norm rather than exception, we > simply cannot ignore threads when designing a generic API for > asynchronous jobs. > > > > The main point of event-driven jobs is to have them use the event loop, > NOT > > threads. > That sounds pointless to me. Why would you design an API for > asynchronous jobs, but limit that to those jobs that use the eventloop? > What does the user of the API really care what the API does to pull of > the async-ness? Compare with QNAM: it uses threading too in the > background, doesn't it? > > To me, a generic job API only makes sense if the API makes sense for all > async operations, no matter if the job itself uses threading or the > eventloop to work. Both should work equally well, and have equal support > IMHO. > > André > > -- > You like Qt? > I am looking for collegues to join me at i-Optics! > > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development >
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development