Unexpected behaviour in slot with Qt::DirectConnection
-
We use lots of plugins in Qt Creator (actually everything but the plugin loader is a a plugin there) and so far never had any issues with connections between plugins. All plugins are in the same thread, too.
-
We do use threading in Qt Creator quite heavily in places. We do also use Direct Connections - even in threads.
Maybe we are just doing it right;-)
Seriously: The plugin loader does not "turn on multithreading". It is just a nice wrapper around dlopen which loads a piece of code into the address space of your application. It does not care what that code does at all.
-
bq. Maybe we are just doing it right
May be. Then just write to documentation how it must be done right. Or Qt still sometimes can work unexpectedly ;-) to it's creators...
I already shown pieces of code which do plugin loading. What is wrong there?
The thread is just like this:@DThread::DThread(MainWindow *parent) : QThread(parent)@
It was developed long time ago and works fine.
@We do also use Direct Connections – even in threads.@
Direct Connections in threads work fine for me except with QtGui - as signed in docs.
-
I am not a lawyer, but the LGPL is not considered to be a proprietary license. You need to pass the your source code on to your customers according to the LGPL. Of course we here are not your customers, so there is no obligation to show it to us:-)
Actually the LGPL does not really make much sense for applications at all I think. You might want to contact a lawyer before sending out your product to your customers.
-
[quote author="Gourmand" date="1308574464"]bq. Maybe we are just doing it right
May be. Then just write to documentation how it must be done right. Or Qt still sometimes can work unexpectedly ;-) to it's creators...[/quote]
This documentation is out there. It just reads:
You must not use direct connections in multi thread signal/slots connections. You do use threads and you do force direct connections. Don't blame Qt for the disaster!
I'll leave it to you to find many more very good documentation on that topic in a prominent place on the DevNet homepage. Additionally there are many other places where all this stuff is mentioned - scan the docs for multi threading stuff, it even has an intro on that. Thousands of developers out there are doing it right - should be worth a thought.
And no, it is not the responsibility of Qt or the doc team to write in every class if it could have unexpected side effects if used in a wild puzzle of application design that no one can foresee, including enforcing stuff that's forbidden.
-
The blame is not about direct connections. They work as expected. Automatic multithreading mode for all plugins connected through signals/slots to multithreading one was truly unexpected. This is not documented. If something goes as not expected and is not documented - this is a bug (documented bug is not a bug but is a feature). Anybody is free to reproduce my design in a manner that I described before. There was no any forbidden stuff enforced. Just legal.
Lets finish this... Now all I created before work well with multithreading. I have some next questions about QWidget in plugin. Will opent another thread for this.
-
There is no "multithreading mode" for plugins.
-
Qt does a pretty good job on deciding if a signal is sent to a receiver in a thread living in another thread and thus falling back to a queued connections. Thousands of developers and applications out there rely on that.
It is up to you to proof that your objects actually live in the same thread and Qt is assuming wrong.
If you're not willing to contribute some sample code for your "proof", then you're on your own. No one here believes in what you claim.
EDIT:
Oh, and just to add: It has absolutely nothing to do with plugins. You would have the very same problem even if you linked the code of your two plugins statically to your application. Point. -
I know for a fact that signal-slot connections between objects instantiated from different plugins behave just like any other connection. If not, than You Are Doing It Wrong(TM), unless you present compelling evidence to the contrary. However, since you won't share an example displaying your issue with us, it will be up to you to figure out what you do wrong exactly. Pointing at Qt is not going to help you. Good luck with that.
Edit:
Note that I don't claim that Qt is bug free. It is not. But this is not one of them. -
There is no automatic multi-threading mode for plugins and so it cannot be documented. What you are seeing is the direct and predictable result of the code you designed and implemented. Whether this was a conscious decision or an unexpected/unanticipated behaviour on your part does not matter. This is not a bug in Qt (either documentation or source).
If you are still convinced that this is a bug in Qt then you will need to spend the time to make small compilable example that reproduces the issue. With this then we or the trolls can help you in fixing it or explaining the code paths that lead to the observed behaviour.
Doing the above is often a valuable process anyway since by doing so you very often find the bug or the key to understanding the issue.
Nobody is trying to accuse you of not understanding signals/slots/connections or multi-threading. Just that sometimes when used in conjunction these topics can lead to what seems like strange behaviour. I have been there myself many times ;-)
Good luck with the rest of your project.