On segunda-feira, 25 de fevereiro de 2013 20.36.24, Sze Howe Koh wrote: > Thank you for the comprehensive explanation. I know little about Qt's > internal mechanisms, so I'm curious now. > > Could the guarantee also be provided by posting QThread::start() into > the event loop during setup? > > QMetaObject::invokeMethod(thread, "start", Qt::QueuedConnection)
Yes, that guarantee could be done like that, but that also implies delaying the start. I'd rather start immediately, potentially allow it to finish immediately, but delay *just* the notification. > If so, what's the cost of having two QObjects (trampoline object and > returned object), and how does it compare to the cost of deferring the > start until the next event loop iteration? It's comparing apples to oranges. One delays the start of the work, so the expense is measured in time, plus a bit of complexity of code to make it start if waitForFinished() is somehow called. The other expense is measured in memory. > In my mind, the costs of 3 different approaches to starting this new method > are: > > - Trampoline object: 2 QObjects, delay of 0 loop iterations, 0 extra > LOC for user > - Queued auto-start: 1 QObject, delay of 1 loop iteration, 0 extra LOC for > user > - Manual start: 1 QObject, delay of 0 loop iterations, 1 extra LOC for > user > > Which costs the "least"? How do the optimizations to the trampoline > change things? Now you're mixing things. First we choose the API: does it start automatically or not? After we've done that, we choose how to implement it and that is an implementation detail. > > QThread signals the status of the thread, but QFutureWatcher signals the > > status of the future, the task. The thread itself may not have finished. > > > > What I'm saying is that you should not return a QThread, but something > > else. And then you can connect QThread's finished() signal to that > > something else's finished(). As I described above, that alone will be > > enough to guarantee the right semantics. > > Then, should we put this new function outside the QThread class? The > task-management interface feels like it abstracts away the underlying > QThread, so it would be messy to mix the API. We could do that, but I think that putting it in QThread also makes sense because that's where people will go to look for it. If this method is restricted to a run-replacement -- a static method that takes a lambda -- then it should be in QThread and it should return a QThread*. It should not be more complex than that. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development