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.

@slilly said:

Can QTimer be called from a normal C++ main and not a QThread or a main using a QCoreApplication?

No. If you want to use QTimer, then you need QCoreApplication::exec() or QThread::exec().

@zzaj
No problem. Good luck with your project!!

Code would help.
And do you see any error messages when your app crashes? Did you try to debug?

@reezeus said:

Is it a good practice to use QThreadPool even if I have only one thread?

I've never used QThreadPool but I can imagine that it eases scaling if you do so... The day you want to increase the number of threads, simply have a bigger pool. On the other hand if you know that one thread is what you need and will continue to need, QThread seems more reasonable IMHO.

I guess you are right. I will work on this without the Threads. Thank you for your help!

@Catherine-Olsen
Could you mark it as such? The topic tools button is on the bottom and when you click it select "Mark as solved".

@Lazar-Urosevic Yes, you can have two QVideoWidgets at the same time. Why should one of them block? And why not just try it?

I'm using this code on the server. By blocking I simply meant that if one client requested something that took long to process it shouldn't block the other clients. I may upload a working sample of this code to github later.

@Wieland
Thank you so much, Wieland. You're 100% right, and I was not lucky enough :)
After moving the sending of finish signal elsewhere, everything goes fine.

@jsulm Thanks! I'll give it a try.

Hi and welcome to devnet,

How are you updating your progress bar ?

@mbruel said:

What do you think, still something to avoid?

You do want to free your resources, while this is usually done in the destructor, that might not always be the case (for example QFile has open() and close() methods, and internal state that it tracks.

For speed optimisation and avoiding signal/slots when possible, well I don't know... I'm new to async programming and still don't really see the point to use a signal/slot mechanism with direct connection instead of directly calling the function on the object. It might not optimize a lot but it should definitely avoid few functions calls and passing by the event queue.

When you connect objects that live in the same thread, you don't have any event queue calls (it's a direct connection, and behaves exactly like you've invoked the function yourself). A reason why you might want to use signals and slots, instead of pure function calls is to decouple components, which is something you'd want for the most part.

I'm wondering if the impressive results of the QT version are due to the C++ and use of native socket or more of the non blocking sockets.

Probably both, although internally (at the OS level) the sockets are blocking, you just don't see it. Also linux sockets, at least to my experience, tend to perform better than their windows counterparts. I don't know why, they just seem to be faster.

I'm having a new problem when I move a second QTcpSocket inside the thread.
Everything seems to work fine but the thread is crashing (segmentation fault) after deletion (after receiving the destroyed signal). It seems to be an desallocation issue... I couldn't manage to figure out the problem yesterday and today...
I'm going to write a easier example of my architecture and open a new post.
Cheers

It is not allowed to use UI related Qt classes in a different thread. They all must be used in the same thread in which the event loop is executed.
Why do you want to use QWebPage in a different thread?
As far as I know the UI of your application should not block while the web page is loaded.

Hi and welcome to devnet,

The only answer I see is: benchmark. You have to test your server under heavy load to see how well it's doing.