Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Call runtime.LockOSThread automatically in NewQApplication #72

Closed
mappu opened this issue Nov 11, 2024 · 10 comments · Fixed by #83
Closed

Call runtime.LockOSThread automatically in NewQApplication #72

mappu opened this issue Nov 11, 2024 · 10 comments · Fixed by #83

Comments

@mappu
Copy link
Owner

mappu commented Nov 11, 2024

Wow. Indeed, calling runtime.LockOSThread() before NewQApplication seems to make it always work.

Originally posted by @ilius in #68 (reply in thread)

@mappu mappu changed the title Calling runtime.LockOSThread automatically in NewQApplication Call runtime.LockOSThread automatically in NewQApplication Nov 11, 2024
@mappu mappu mentioned this issue Nov 11, 2024
@ilius
Copy link

ilius commented Nov 13, 2024

Although if NewQApplication itself is called in another function which is called in main(), this may not fix the problem (I had that issue in FreeBSD).
I think runtime.LockOSThread() should be called directly inside main().

@mappu
Copy link
Owner Author

mappu commented Nov 18, 2024

@ilius Are you sure?

The documentation for LockOSThread says it should affect the entire goroutine indefinitely. It doesn't stop taking effect when returning from the function, it only stops taking effect when explicitly unlocking with UnlockOSThread.

But, real experience beats documentation.

Sorry to bother you but since I can't currently reproduce this, would you be able to remove your own calls to LockOSThread and try the branch from #83 ?

@ilius
Copy link

ilius commented Nov 18, 2024

I got this error with #84 on FreeBSD.
https://gist.github.com/ilius/48a96df3d4acd5cb06757f77dcbb7ceb

Then I ran sudo rm -rf $GOPATH/pkg/mod/github.com/mappu/miqt\@v0.* and go build again, but it finished quickly.
So I ran rm -rf ~/.cache/go-build/ and go build again, and I got the same error as above.

@ilius
Copy link

ilius commented Nov 18, 2024

I get this error on master as well.
I might have updated my Qt since last build.
How to fix it?

@mappu
Copy link
Owner Author

mappu commented Nov 18, 2024

Cannot mix incompatible Qt library (6.7.3) with this library (6.7.2)

I think this is caused by a mismatched version of your qt6 and qt6-multimedia packages. Really they should have the same version. Can you check in your package manager if there are more updates?

@ilius
Copy link

ilius commented Nov 18, 2024

They are both 6.7.3, the latest version in FreeBSD repo.

@ilius
Copy link

ilius commented Nov 18, 2024

Oh, qt6-base was older.

@ilius
Copy link

ilius commented Nov 18, 2024

FreeBSD's pkg is not as clever as Linux's apt or dnf I guess!

@ilius
Copy link

ilius commented Nov 18, 2024

Moving runtime.LockOSThread out of main() func to before qt.NewQMainWindow works now.
Maybe I was doing something wrong before!

Also #83 without runtime.LockOSThread works.

Next I reverted back miqt to master (still no runtime.LockOSThread), compiled and ran, this time with no error! But the app window does not show up! Did they change something in Qt 4.7.3 that caused this (it sounds worse!).
Edit: tried for 3rd time and got the old Cannot create children for a parent that is in a different thread error.

Anyway, #83 fixes it.

@mappu mappu closed this as completed in #83 Nov 19, 2024
@mappu
Copy link
Owner Author

mappu commented Nov 19, 2024

Thank you @ilius for the extra testing. It is difficult to reproduce this intermittent issue, so I'm really glad to hear that #83 solved the issue for you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants