how to defined a slot when is call is executed on separately Qthread c++?

Reply to how to defined a slot when is call is executed on separately Qthread c++? on Thu, 20 Aug 2020 16:14:18 GMT

JonB — Thu, 20 Aug 2020 16:14:18 GMT

@stackprogramer
I wouldn't use waitForBytesWritten() either, it's just another blocking call (so it requires a thread), I'd just use the signals. And I don't see it tells you that much about what's really going on anyway.

But you know more about your situation than I do. Maybe you do need your threads for some reason.

Reply to how to defined a slot when is call is executed on separately Qthread c++? on Thu, 20 Aug 2020 15:16:49 GMT

stackprogramer — Thu, 20 Aug 2020 15:16:49 GMT

@JonB
we have problems when we write large data on serial port and time writing on port is long time(For large file we have to slab data file and....sending it) and other serial port signals is triggered ..........we observe sending data is not real time and we have delay....because an other slot port is executed but first port serial yet is writing........and finally .....
we have lag in sending files....

  serialPort->write(serialDataResponse);
                        serialPort->waitForBytesWritten(300);

Reply to how to defined a slot when is call is executed on separately Qthread c++? on Thu, 20 Aug 2020 07:33:22 GMT

JonB — Thu, 20 Aug 2020 07:33:22 GMT

@stackprogramer
I don't see why it matters whether you are managing 1 serial port or 100 serial ports. I would expect Qt's asynchronous signals/slots to handle this without any need for threads. That's all I can say.

Reply to how to defined a slot when is call is executed on separately Qthread c++? on Thu, 20 Aug 2020 07:30:22 GMT

stackprogramer — Thu, 20 Aug 2020 07:30:22 GMT

@JonB said in how to defined a slot when is call is executed on separately Qthread c++?:

Just to say: of course I do not know what exactly your code does. But people keep introducing threads --- which are complex in Qt --- to do things where Qt's existing asynchronous signal/slot architecture should mean there is no need to do so. When using serial ports I see lots of people start using separate threads to handle blocking serial port calls, when they would be much better using no thread but non-blocking signals like readRead() instead. So I hope you really know what you are doing/have a use case....

Hi @JonB thanks for attention yes i know your solution but we have should used threads because we should manager 7 serial port and udp....a little delay we have lost

we should managed timing input and output data

Reply to how to defined a slot when is call is executed on separately Qthread c++? on Thu, 20 Aug 2020 07:14:32 GMT

JonB — Thu, 20 Aug 2020 07:14:32 GMT

@stackprogramer
Just to say: of course I do not know what exactly your code does. But people keep introducing threads --- which are complex in Qt --- to do things where Qt's existing asynchronous signal/slot architecture should mean there is no need to do so. When using serial ports I see lots of people start using separate threads to handle blocking serial port calls, when they would be much better using no thread but non-blocking signals like readRead() instead. So I hope you really know what you are doing/have a use case....

Reply to how to defined a slot when is call is executed on separately Qthread c++? on Thu, 20 Aug 2020 07:00:19 GMT

stackprogramer — Thu, 20 Aug 2020 07:00:19 GMT

Finally i used this way. i didn't used subclass as thread i used only a thread and i moved port serial to on it....

    QThread* thread = new QThread;
    serialPort->moveToThread(thread);
    thread->start();

Reply to how to defined a slot when is call is executed on separately Qthread c++? on Wed, 19 Aug 2020 09:20:31 GMT

JonB — Wed, 19 Aug 2020 09:20:31 GMT

@stackprogramer
Put the two slots separately in each of the two separate threads you want each one to execute in. I don't know how to answer better than that.

Don't forget that if you are using multiple threads you cannot/must not do an UI operations in anything other than main UI thread....