[Development] A QtCore class for event-driven jobs

[Konstantin Ritt]

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 <andre at 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 at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130912/755a7246/attachment.html>