@sebs What I don't understand: you want an application with 3 threads, right? But why do you create new process?

Hi Its sounds like the classic worker - processing - display design with the twist of caching signals in processing. In my opinion is a very good design. :)

@kshegunov I understand, and respect your opinion on the matter but... I doesn't agree with most of them. Not wanting to make a big discussion of it, (mainly 'cause it's really out of the scope of the post) but... let's see: A singleton is not a real object, it's a facade for a global variable Well, yeah. I would say it's a (much) more elegant way to create a "global variable", since it ensures that only one will be created. A singleton created on the stack is initialized before main, so anything that actually depends on things done in main() as QObject does, may or may not work. Well, the way I learned to implement singleton on C++ uses heap. A singleton that's constructed on the heap often is simply left undeleted - a memory leak. C++ is not JAVA, it's the programmers job to clean the memory up. Well, I'm not seeing a problem here. I dont mind putting a few deletes at the end of my main, or even connecting some signals. A singleton that's created on first use in the heap requires special measures to be taken, so the construction is thread safe. Again, not seeing a problem here, just a need to take some caution when coding. A singleton created on the stack can't guarantee order of initialization (whence point 2 derives). If you have more than one the loader will initialize them depending on its mood! Again, I don't create them on stack. A singleton that's created on the heap can't guarantee order of initialization ever! Not really sure what you mean here. A singleton is a global shared public resource in your application that promotes coupling, it actually couples every one of the classes that decide to use it. Some times you need that coupling. You need to center the processing in one point in the code. That's what controllers are all about. A singleton is not thread-safe by design, and can't be reentrant as there is only one. Not really. For data classes, you're right. But for controllers, they can be thread safe as long as their attributes are read-only Why your worker object should not be a singleton My worker object is not a singleton. My controller object (the one that creates the worker objects) is. The fact that something is called a "design pattern" in some book, doesn't mean you should use it. But means that it have its uses.

Hi, Please don't post the same question multiple times. If you have additional informations to add to your thread, you can edit the post. rather than deleting it and write a new one.

Many thanks for all your help, I now switched from postEvent to sendEvent, so it is not like fire and forget and I can handle the returns. Also now I can fire a lot of sendEvents and no crash appears anymore. So this solves it for me. Regards

How can i create my signal for text edit with python3 ? With as many ways i tried, but I did not succeed .. :(

@Jeroen3 Thank you for your sharing!

I'm really unsure of how to address this problem so i will explain it first. I need to run a number of threads that each connect to some application via TCPSocket, so far no problem. The application is quite time consuming that is why i want it to run parallel on multiple threads and one thread each to communicate with it. Once the computation is finished i want to send the results to another thread collecting the results. Therefor i wrote a Worker class. Now that superThread is supposed to work off a huge file and needs to spread it around the threads, and then receive and handle the results. My approach so far is another superThread that is connected in the main() as follows: QThread* superThread = new QThread(); supWorker* super = new supWorker(); for (int i = 0; i < nrWorkers; i++){ Worker* worker = new Worker(portRange+i); QThread* workerThread = new QThread(); QThread::connect(workerThread, SIGNAL(started()), worker, SLOT(connect())); worker->moveToThread(workerThread); workerThread->start(); QThread::connect(super, SIGNAL(process(int, QString, int)), worker, SLOT(process(int,QString,int))); QThread::connect(worker, SIGNAL(finished(int, int, QString)), super, SLOT(handleResult(int, int, QString))); } The problem this way is obviously that i can only send the SIGNAL to all connected threads. What i want the superThread to do is send arguments to only one of the threads. I don't know how i can handle the connection so that only one of the working threads receives it? Any help or architectural ideas much appreciated, thanks in advance.

You don't actually need to subclass QAbstractItemModel with your current approach. Your QList<SoundObject*> already acts as the model. In fact, I want to use a QSortFilterProxyModel in C++ to filter what I want to display, and a TableView in QML to enable multiple selection, which is not available in ListView :( So I had to subclass QAbstractItemModel, and add a custom role that I named "data", which returns the QObject*. Thank you for everything, I'm going to implement this right away. If I find something useful, I will share it here. And if someone has another idea/vision of how to solve the problem, don't hesitate to share too !

@Chick3nN00dleS0up You're welcome :-)

I have followed your solution but still have the same problem. I am binding the defaultFrameBufferObject() accessed via the shared context in my rendering class but it's still not drawing on-screen. Could you please update the code to include your implementation of the binding operation?

I suggest to use the readyRead() signal to be notified when some data arrive on the socket