I don't have any use cases, but I can't imagine the example recommendation of
connect(thread, SIGNAL(finished()), worker, SLOT(deleteLater())); working as expected unless deleteLater() happens on the same thread as finished(), via a direct call. So AutoConnection 'happens to work' because of an implied contract of how finished() works. I'm not looking at this stuff for any _particular_ purpose, but to - make sure it is suitable for the purposes it will likely be used for - recommend how to use it and when to use it So I'd like to understand how it works. Maybe that means looking more at the code than the docs. But the code can change - the real "contract" is in the docs. Basically, I think APIs (and UIs) should be like hammers - I know how a hammer works just by looking at it. There is no magic involved. QThread is still more magic that clarity. IMO. From: Sze Howe Koh [mailto:[email protected]] Sent: Tuesday, October 09, 2012 11:12 PM To: Tony Van Eerd Cc: [email protected] Subject: Re: [Development] QThread usage/guidance On Wed, Oct 10, 2012 at 1:20 AM, Tony Van Eerd <[email protected]<mailto:[email protected]>> wrote: Speaking of docs, should the docs for the started() and finished() signals note which thread these signals are sent from? ie finished(), even in http://doc-snapshot.qt-project.org/5.0/qthread.html#finished and I think in https://codereview.qt-project.org/#change,36301,patchset=3 and http://qt-project.org/forums/viewthread/20691/ , just says "This signal is emitted when the thread has finished executing." I know it only matters for DirectConnections, but it isn't clear whether the signals originate from the QThread's thread, or, uh, the QThread's thread. ie the QThread's affinity thread (which would be true, I suppose, for normal objects) or on the thread managed by the QThread. And if I had other comments on the docs, where's the best place? Maybe the forum (http://qt-project.org/forums/viewthread/20691/)? Do you have a use case where the program can't rely on Qt::AutoConnection, and instead requires a specific connection type? (or at least requires knowledge of the invoking thread?) I can't think of one myself -- if I'm not mistaken, developers shouldn't need to care about the signal's thread of origin; they only need to choose the thread for the receiver/slot. But if it's important, we can (and should) add the information to the docs. Post comments under the relevant sub-task at https://bugreports.qt-project.org/browse/QTBUG-16358. If a sub-task wasn't created for the page, post in the forum thread you mentioned. Cheers, Sze-Howe --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
