[Development] Evolving Qt's multithreading API

[Thiago Macieira]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130225/e0a91338/attachment.sig>