I've been sitting silent on this, but I am quite in favor of having an easy to understand approach to using QThreads, which the proposal in this thread seems to be.
> From: Thiago Macieira <[email protected]> > To: [email protected] > Sent: Monday, February 25, 2013 11:06 AM > Subject: Re: [Development] Evolving Qt's multithreading API >> 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? >> 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. How about a parameter to the function(s) that specifies whether to auto-start or not; default could be either way. Personally, I can easily seem myself replacing my current QThread usages with this functionality; but I'd want to be able to receive both start/finished signals (for logging purposes) and be able to interact with the QThread object - so the Trampoline object would need to provide an interface by which to access the internal QThread, or be a pass thru for signals/slots of the QThread. Of course, I mostly deal with long living threads; but my point of using the new interface would be (i) the simplicity, and (ii) the clarity. $0,02 Ben _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
