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.
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.
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.
@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.
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.
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.
Спасибо за объяснение, я Вас понял, я добавил 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.
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.
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.