Invoking singleton from thread gives me :QObject: Cannot create children for a parent that is in a different thread
-
hi ( again )
working with the threads in Qt i see there are some mistakes im doing when involving Thread
now in this case i have QThread work that i invoke like this :@ m_MyThread = new QThread();
m_MainWorker = new MainWorker();
connect(m_MyThread,SIGNAL(started()),m_MainWorker,SLOT(doWork()));
m_MainWorker->moveToThread(m_MyThread);
m_MyThread->start();
@inside the worker thread i invoke http request call , the http request call is setup in singleton object that handle all my
http stuff . when i invoke this singleton from my worker thread im getting this error from Qt :@(Parent is QNetworkAccessManager(0xde2ef0), parent's thread is QThread(0xcacc00), current thread is QThread(0x33040e0)
QObject: Cannot create children for a parent that is in a different thread.@do i need to use again signals and QMetaObject::invokeMethod , but now from the Thread worker to invoke the http singleton ?
-
The QNetworkAccessManager created in the singleton does not belong to thread issuing the request, as the singleton was created resp. initialized in another thread. The solution is to create your own QNetworkAccessManager in your <code>MainWorker</code>.
@
class MainWorker : public QObject
{
public:
MainWorker(QObject* parent = 0) : QObject(parent)
{
// make sure you pass this as a parent to the QNetworkAccessManager,
// so it gets moved along with your QObject to the new thread_manager = new QNetworkAccessManager(this); ... }private:
QNetworkAccessManager* _manager;
};
@
Do not use singletons, they are an anti-pattern (exceptions prove the rule). -
-
[quote author="Gerolf" date="1327653811"]I would not sign this. They should not be used for QObjects, yes. But this should not be said in a general manner :-)[/quote]
Of course this is my personal opinion. But unless someone comes up with an inevitable use case for singletons which justifies the drawbacks (notably unit testing horror, reduced parallelism and synchronization overhead, object responsibility violation, design obscuration) I keep calling them what they are, a relic anti-pattern which shouldn't find itself in newly created code ;-)
I mean, there seems to be a global consensus that global variables are evil incarnate, but when it comes to singletons - which are just another representation of global variables - everyone goes uhm... well... it seems like they are not that bad at all - kind of weird, isn't it? :-)
I'm talking about the classic singleton pattern here, not the concept of having classes working properly only with a single instance (as eg. in QCoreApplication)!
-
There is a good "techtalk":http://www.youtube.com/watch?v=-FRm3VPhseI with Misko Hevery, who also blogs about it ("#1":http://misko.hevery.com/2008/08/25/root-cause-of-singletons/, "#2":http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/, "#3":http://misko.hevery.com/2008/08/21/where-have-all-the-singletons-gone/). There is are also a good summary at the "MSDN blog":http://blogs.msdn.com/b/scottdensmore/archive/2004/05/25/140827.aspx, which is nowhere near the "only one":http://blog.code-cop.org/2012/01/why-singletons-are-evil.html - "Google":http://www.google.at/#q=singleton+evil is basically full of it.
-
While I do see some good arguments, it mostly boils down to "it makes unit testing hard". That may be an important argument for some cases, but not for all, I think. Unit testing is one way of testing code for compliance, but not the only, and not for all types of code. The question he pretended not to understand correctly in the presentation was telling, if you ask me.
-
Singletons probably won't hit you immediately (except you are doing unit testing or multithreaded programming), but as with every bad design choice they involve a potential problem that might hit you at any time - with an increasing probability the lager a project becomes. And a global state, tight coupling and the violation of the single responsibility rule are huge problems when they become a problem.
There are situations where singletons do make sense, but in 90% of cases singletons are just misused and they are used as a substitution for a global variable - and in the remaining 10% the classical singleton pattern can be most probably substituted with another singleton-like design pattern. In my humble opinion this fact alone qualifies them as an anti pattern.
But enough of derailing this topic! :) Let's end it with a riddle: who said "When discussing which patterns to drop, we found that we still love them all. (Not really—I'm in favor of dropping Singleton. Its use is almost always a design smell.)"?