@J.Hilk said in Passing custom type pointers between threads via signals and slots cause app to crash:

you should probably wrap that in manager class instead.
Since than I always have a manger object that forwards stuff via signals or from its own memory when exposed directly.

I was going to do it like this.

Let's clarify some aspects of your approach.

Manager <-> Threads : communicate via signal/slots with QueuedConnection synchronization/locking on the shared resource

@J.Hilk said in Passing custom type pointers between threads via signals and slots cause app to crash:

manger object that forwards stuff via signals or from its own memory when exposed directly.

Manager <-> QML signals and slots or directly from manager's memory

Have I figured it out properly?

@Yash001 You can three classes & inheritance mechanism as you mentioned. I'm keeping aside the topic of why not to inherit from QThread.

I dont know why, but if I set the conexion between server and client first and then I call the function startSerialPort(), the reading speed is the normal. But this method just works with the first conexion. The second conexion already experiment the decrease of the reading speed.

void MyServer::startSerialPort() { mipuerto2 = new MySerialPort; msgRec = new MensajeRecibido; msgSent = new MensajeEnviar; connect(mipuerto2, SIGNAL(msgChanged(QByteArray*)), this, SLOT(getMens(QByteArray*))); connect(mipuerto2, SIGNAL(msgChanged(QByteArray*)), this, SLOT(idMensaje(QByteArray*))); connect(msgSent, SIGNAL(tienesMensaje(QString*)), this, SLOT(setRecibido(QString *))); mipuerto2->openSerialPort(); } qDebug()<<socketDescriptor<<"Connecting... "; socket = new MySocket(socketDescriptor); controlador++; QThread *thread = new QThread; qDebug()<<thread->currentThreadId(); connect(this, SIGNAL(mensChanged(QByteArray*)), socket, SLOT(getMsg(QByteArray*))); connect(socket, SIGNAL(mensajeEnviarSocket(QByteArray*)), this, SLOT(sendMens(QByteArray*))); connect(socket, SIGNAL(disconnected()),thread, SLOT(quit()) ); connect(socket, SIGNAL(disconnected()), socket, SLOT(deleteLater())); connect(thread, SIGNAL(finished()), thread, SLOT(deleteLater())); connect(thread, SIGNAL(started()), socket, SLOT(funcionamiento())); connect(socket, SIGNAL(disconnected), this, SLOT(desconectar())); socket->moveToThread(thread); thread->start(); if(controlador==1){ startSerialPort(); }else if (controlador>1) { mipuerto2->closeSerialPort(); delete mipuerto2; startSerialPort(); }

@koahnig You were right, changing the pointer this to socket in the connection function of readyRead, it worked. Thanks you

@CP71 Dont worry, you are helpful. I will tried to find the trouble, I know that must be in my Code of the server, because in the first Code that I published in this thread I could do It. And in a simpler Code for just one connection server-client It also worked.

@VRonin
Thank you, it works perfectly. I thought that ‘this’ could not be called inside a thread.

Hi @Md0ngo said in QThread signals|calls to QChart are blocking the GUI:

After so much time lost, solved it!!

It seemed to be the fault of the default QSeries implementation... Series.append() apparently emit a couple of signals and resize the inner vector which contain the QPoints. This combined to a O(kn²) loop totally messes up the main event loop.

It was "as easy" as refractoring the code so the thread builds up a QVector of QPoints, then signals each vector to the chart and it calls to series.replace() instead of append(), that is actually faster and lighter.

great that you were able to fix it yourself, and I learned something new and important about QCharts thank you ;-)

I was about to give up after trying the moveToThread way without success, but I was lucky enough to get the solution after finding this.

So, not a matter of Qthreads after all.. Now I'm wondering whether refracting the code to create a dedicated event-loop was worth it or not.

If an actual worker class is now replacing your infinite while loop, that you posted in the op, than yes it is, definitely!

Don't forget to set your topic to solved ;-)

@dheerendra At this point, we are fairly certain that the problem is in the main thread code. I have uploaded the main thread code in the previous comment. Please suggest any necessary changes that could solve the issue. thank you.

Perfect !!!! What a group !!! Thanks very much, this save me a lot work !!!

This is an awesome new feature and now I can use it.

Rick

Hi,

Looks like there's some problem with the PySide 2 implementation. You should check the bug report system to see if it's something known. If not, please consider opening a new report providing your example and as much details as possible about your current setup.

I agree you need to use a state machine for that case. http://doc.qt.io/qt-5/qstatemachine.html probably helps putting down the skeleton already

Please excuse my late reply. I wanted to think about this a bit.

I guess we all agree that the documentation is not wrong. It clearly states that slots are not executed in a separate thread when subclassing QThread. Personally, I also feel like this is not exactly "buried" in the documentation.

The main problem I see is that people that start coming across QThread are getting misleaded very easily by those famous blog posts that try to tell you how to do it, and then not to do it like that, but then again, it's apparently fine too.
I feel like the a paragraph could be added to the documentation which clearly states when subclassing QThread is needed and when not. Basically a: "Only subclass QThread if ....
Which might be followed by a "Things to keep in mind" bullet list which lists the "special properties" or "pitfalls".

At the end it really just boils down to the fact that QThread is not a thread but just a thread wrapper. From my personal experience I feel like this is very different from how other frameworks provide threading.
Of course I understand that renaming QThread is out of the question but I feel like some very generic information paragraph in form of a bullet list might help a lot.

Thanks, I will check!

@Buckwheat Thank you documents link. I will read it and trying to make change in my code. thank you @Buckwheat .

I feel like this is a perfect personification of the "came searching for copper but found gold meme", Sometime in the past I acknowledged that modifying UI elements in a secondary thread caused crashes, I even fixed it, then when I moved my project from computer to computer i must have copied an old file or something, and forgot that that was a no-no. But I digress, not only did this thread solve my problem, it also showed me a way to ditch cURL, and rely solely on QT, as well as circumvent the necessity of the threading in the first place, so thank you all for answering my question and more @Buckwheat / @VRonin /@kshegunov

response is quite different from QImage, so you should start by matching your function prototypes. To that end you should use the Qt5 connect syntax, which is going to throw you a compile-time error for that code, as it justifiably should. I don't understand the rationale between that global variable - response cevap; though, you should explain what prompted you to use it like this.

@VRonin Merci :-)

@jsulm
Yeah, i understand (just forget to start thread). In that example thread->start() was called though.
In the last example deletion of ThreadEx object should be handled by application main loop.

@SGaist I need the slot send_console_log to be called when the signal written in ConsoleStream is emitted. When running the program with a normal while/for loop in the interpreter, the slot will be called becuase at that moment its non blocking. But the moment I add time.sleep into a loop, slots will only be called at the end when all the blocking is over. Thank you for looking into this.

@mrjj Cheers, that worked for me :)

@BjornW said in Signal and slot to synchronize variable between qthread:

I would separate the objects into two types. One type that is the "master" object and other objects which interact with it.

That's the correct thinking, I consider this whole question to be a design issue. The problem I see is that a dependency is introduced between two QObjects that are in different threads, that is very unnatural to begin with - the two objects shouldn't depend on one another implicitly; it's no mistake that a QObject instance can't have a parent that's living in another thread. In my mind either the dependency should be declared explicitly (e.g. manually synchronizing the objects across the threads in some fashion) or it shouldn't exist at all.

@J.Hilk

Thanks, I was checking wasCanceled() in several places but not just before applying the new value. I was rather sceptical that it would work, but it did.

Still, I would have liked to have learned a better scheme for handling the progress.

Never mind,

I had code in my the constructor of the to be threaded class, that caused the conflict...

connect(&modbusThread, &QThread::started, modbusDevice, &Modbus::setupClass);

fixed the issue.

Ok, thanks, I think I have all information I need now.

Frankly, I forgot about it.

Then it also depends also on what tools fits best your needs. There's no silver bullet that will cover everything you need.

Also limiting yourself to only one language is not a good idea in the long run. There are good and bad things in every language thus knowing more than one allows to have a better grasp at what can be done, how easy/hard the maintenance would be etc.

That crashes because you have to put every worker-> inside a if(worker) to make sure you are not operatng on a null pointer.

Can you tell me the exact sequence of operations that lead to the problem?

@Ahti
Please read how C++ manages objects' lifetimes.

For the FAQ:
https://isocpp.org/wiki/faq/dtors#dont-call-dtor-on-obj-allocd-via-new

Спасибо за объяснение, я Вас понял, я добавил moveToThread() перед connect() мне это не помогло, наверное, делаю что то не так. Я попробовал вариант, когда наследуется класс от QThread и в его методе run выполняется нужная функция. В этом случае потоки выполняются параллельно, но мне этот вариант с точки зрения ООП не очень...
Буду благодарен за советы!

The export (or lack thereof) definitely was the problem. Once I got in this morning and cleaned up by code a little and rebuilt everything the export is now working fine. I must have had an old build of something that wasn't getting cleaned.

Anyway thanks for the help!

Hi,

What about doing the subscription related stuff in your proxy ? Basically two methods:

FeedProxy::subscribe(YouCoolClass *) FeedProxy::unsubscribe(YouCoolClass *)

No need for any special detection and you know exactly where things are happening.

I had to add Q_OBJECT and also delete my debug folder once, to get rid of a few link errors.

Also got rid of the QThread subclassing, it is way easier to create a worker class and connect it through signals. There is really a lot of outdated example code out there.

Thanks for your help!

@beecksche said:

The advatage of a QScopedPointer is that you don't have to care about the destruction of the object, right?

Yes. It's a thin wrapper around the raw pointer and will delete the held reference when it goes out of scope. The idea is to use the stack based QScopedPointer object to manage the heap-allocated object it's referencing.

Kind regards.

Thanks for your reply and help!

It is working now and the reason was the listen() was in the wrong position and you need an additional Signal/Slot connection from main program to the network extension as following:

the main program gets changed like this:

wifi= new WirelessNet(0); QThread *thread = new QThread; wifi->moveToThread(thread); connect(thread,SIGNAL(started()), wifi,SLOT(initWifi())); thread->start();

the constructor of WirelessNet is now empty, therefore it gets a new public slot function:

void WirelessNet::initWifi() { listen(QHostAddress::Any, 5220); }

And that's the trick.

If one is creating a WirelessNet-Instance, starts listenting inside the constructor but first then uses the movetoThread(), the connection is lost.

Concluding in one sentence: First move to the right thread and afterwards start listening

Thanks for your help. Let me tell you I hate the official Qt-""Tutorials""

@QtExchange
Forgot to link those two, which are very important to understand before working with threads:
QObjects' thread affinity: http://doc.qt.io/qt-5/qobject.html#thread-affinity
Queued connections accros threads: http://doc.qt.io/qt-5/threads-qobject.html#signals-and-slots-across-threads

Hi and welcome to devnet,

Are you also new to coding ? If so, then don't start with threads, that's a pretty complex subject that you should take on later after getting the basics correctly.

Also, for what you described there's no need for threads. Qt's asynchronous nature already provide what's needed.

Start with Qt's documentation. It also contains the Threading Basics

On a side note, it's Qt, QT stands for Apple QuickTime which you might also be interested in.