Multithreading, QML, plugins and ... Crashes!

[vltr]

Hello @benlau ! Me again. I hit the same problem while integrating QuickFlux into my application: it uses threads and plugins and everything weird that call all mutexes and locks in the world in Qt Quick and the problem appears again to me and the solution is now to call it by hand.

Well, can I make a suggestion or two? We can use defines to register (or not) the Qml types at runtime, letting users with more complex apps to decide and also test QuickFlux as a plugin for Qt itself -- instead of embedding it into the app. The first one is quite easy to accomplish, the second one I can work to make it happen.

I would like to help with CMake also (as yet open in issue #1) if some spare time help me. Meanwhile, I'll focus on .pro and .pri because CMake on Windows with MSVC is quite, well, you know.

Best regards,
Richard.

[vltr]

Ok, I did created a define called QF_NO_STARTUP which disables the "auto-registering" and provides a method to be called after QGuiApplication being initialized in a complex environment. Also created a .pro for Qml types as a plugin, but I'll have to test it (and create examples and more test case units) before creating any PR.

Anyway, if you want to see the progress, please check the repository on my userspace.

My best regards!
Richard.

[benlau]

Hi @vltr,

It uses threads and plugins and everything weird that call all mutexes and locks in the world in Qt Quick

I want to clarify your problem first. Are you calling both of Qt Quick and Quick Flux function in non-main thread? If my understanding is correct, it is not valid in Qt Quick. Although Qt Scene Graph may render content in non-main thread, Qt Quick itself is single thread. It should update its content on main thread only. (And that is why Quick Flux do not use mutex).

I would like to help with CMake also (as yet open in issue #1)

Yeah! It will be great. I don't really have time to handle CMake stuff.

[vltr]

Hey Ben!

I'm on traffic right now, but I think I did not explained the whole
scenario, where the mods I made yesterday worked successfuly. I'll explain
better ASAP so we can be in the same page :)

Best regards,
Richard.
Em 2 de jul de 2016 10:46 AM, "Ben Lau" [email protected] escreveu:

Hi @vltr https://github.com/vltr,

It uses threads and plugins and everything weird that call all mutexes and
locks in the world in Qt Quick

I want to clarify your problem first. Are you calling both of Qt Quick and
Quick Flux function in non-main thread? If my understanding is correct, it
is not valid in Qt Quick. Although Qt Scene Graph may render content in
non-main thread, Qt Quick itself is single thread. It should update its
content on main thread. (And that is why Quick Flux do not use mutex).

I would like to help with CMake also (as yet open in issue #1
#1)

Yeah! It will be great. I don't really have time to handle CMake stuff.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#9 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/ABeAs6fQ6RRoDf80xR5CNHytrOm0v_M2ks5qRmuigaJpZM4JDGWz
.

[vltr]

@benlau yeah, well, first the main problem, let me explain it a little better: I have an app that looks kind Qt Creator: it has a lot of plugins or, more specifically, plugin centered. Some of these plugins brings QML resources where I embed settings and some other features and, since Quickflux is very useful, I was porting some of my plugins to use it. But, starting it automatically (like in issue #7) in this case produced the same error (even if added to the main launcher project), leading me to believe that when loading plugins, that Qt macro used to solve #7 is called before any gui. It only worked when I called it after QGuiApplication. I created a .pro file also to export QuickFlux as a Qt plugin, which is kind the way every QML type is exported by Qt in its source code (I mentioned mutexes because of Qt's source code on QML type registration, it looks like a mutex / lock nightmare).

Does this sounds reasonable?

My best regards,
Richard.

[benlau]

I see.

So the requirement is to have an DEFINE to disable Qml types registration and a function to let user to register on their own type? I think it is fine to provide those functions. However, I don't suggest to use Quick Flux in a plugin because the AppDispatcher is a singleton object per QQmlEngine. Is it ok?

[vltr]

Thanks, @benlau ! Yes, the DEFINE looks legit (IMHO), because it makes Quick Flux more flexible (for those who RTFM - I can work on that in my repository, if you want).

I did not knew that as a plugin, it would cause such misbehavior. In case of a lib, shared, would it work fine (since I'll have to link to its lib and call the register function in my runnable anyway) ?

Best regards,
Richard.

[benlau]

Added.

4020a0f

[vltr]

Yay \o/ ! Thanks @benlau ! Now it's free for the user to set what he wants 😄

[vltr]

In my spare time I'll see what I can do with CMake. CMake is beautiful in the posix land, but in Widows ... Well, that's why I keep project files. The problem will be to choose one or another OR keep both in sync.