On 10 October 2012 16:00, Tony Van Eerd <[email protected]> wrote: > 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.
Why do you say so? Without looking at the implementation, the theory should tell us: 1) finished() emitted from the "new thread", QThread living in the "parent thread": a queued call is used automatically. Since you can't be certain about when the event loop in the parent thread picks the deletion event up (*) and tries to delete the QThread object (which can happily crash your program, if the managed thread is still running), lock a mutex before emitting finished() and unlock it when you're really done with the thread. Then lock the same mutex in the QThread dtor, so it can't be run while you're cleaning up. (*) ... the long story is that first the metacall event is picked up, which causes deleteLater to be called, which in turn posts the deferred delete event. 2) finished() emitted from the "new thread", QThread living in its thread (moveToThread(this), etc.): direct connection used automatically, which will cause deleteLater to immediately post a deferred delete event. It will be picked up some time later (i.e. it won't deadlock with the aforementioned mutex), when the last round of deferred events is dispatched. By carefully coding it, you can achieve "delete this" in C++. 3) finished() emitted from the "parent thread", QThread living in the "parent thread": this requires us to reason about how do you emit such signal from the parent thread. If you resort to post an event to the QThread instance, event which will be dispatched from the parent thread's event loop and will cause the emission of the signal, you pretty much reinvented 1)... (Before you think about doing something strange, you can't emit Qt signals from, say, UNIX signal handlers.) 4) finished() emitted from the "parent thread", QThread living in its thread: this can't work in all cases, as the deletion event may be posted (to the thread's own event loop) after the thread itself has fully finished. In other words, this will leak the QThread instance; it's the equivalent of posting an event to an object living in a thread without an event loop running. Cheers, -- Giuseppe D'Angelo _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
