Run all GTK dialogs on one thread #152
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Per the GDK documentation: "GTK+, however, is not thread safe. You should only use GTK+ and GDK from the thread gtk_init() and gtk_main() were called on. This is usually referred to as the "main thread"." We were previously calling GTK functions from different threads--there was a mutex so that only one thread was calling GTK at any given time, but that's not sufficient--only the thread *that called gtk_init* is allowed to call GTK functions. To facilitate that, spin up a thread and initialize GTK on it, keeping it alive for the lifetime of the program. It's a bit unfortunate that we have to keep it around forever, but the GTK documentation seems to indicate that once you call gtk_init on a thread, you're stuck with that thread.
PolyMeilex
approved these changes
Sep 28, 2023
There was a problem hiding this comment.
Yeah, this is a decent solution, not much else we can do about this global state bs on C side.
This will obviously blow up as soon as someone has other code that also uses GTK, but let's ignore that for now, as I want to get rid of GTK backend one day anyway (#66).
This was referenced Sep 29, 2023
notriddle
added a commit
to notriddle/plugins-workspace
that referenced
this pull request
Dec 5, 2023
PolyMeilex/rfd#152 conflicts with the way tauri uses it. > Yeah, this is a decent solution, not much else we can do about this global state bs on C side. > > This will obviously blow up as soon as someone has other code that also uses GTK, but let's ignore that for now, as I want to get rid of GTK backend one day anyway (tauri-apps#66). Yes, Tauri is other code that also uses GTK, and it does, indeed, blow up. The best way around this is to stop using rfd entirely (they're planning to drop the GTK backend, which will probably break since the XDG Portal API doesn't cover message dialogs).
notriddle
added a commit
to notriddle/plugins-workspace
that referenced
this pull request
Dec 5, 2023
PolyMeilex/rfd#152 conflicts with the way tauri uses it. > Yeah, this is a decent solution, not much else we can do about this global state bs on C side. > > This will obviously blow up as soon as someone has other code that also uses GTK, but let's ignore that for now, as I want to get rid of GTK backend one day anyway (tauri-apps#66). Yes, Tauri is other code that also uses GTK, and it does, indeed, blow up. The best way around this is to stop using rfd entirely (they're planning to drop the GTK backend, which will probably break since the XDG Portal API doesn't cover message dialogs).
notriddle
added a commit
to notriddle/plugins-workspace
that referenced
this pull request
Dec 5, 2023
PolyMeilex/rfd#152 conflicts with the way tauri uses it. > Yeah, this is a decent solution, not much else we can do about this global state bs on C side. > > This will obviously blow up as soon as someone has other code that also uses GTK, but let's ignore that for now, as I want to get rid of GTK backend one day anyway (tauri-apps#66). Yes, Tauri is other code that also uses GTK, and it does, indeed, blow up. The best way around this is to stop using rfd entirely (they're planning to drop the GTK backend, which will probably break since the XDG Portal API doesn't cover message dialogs).
FabianLars
added a commit
to tauri-apps/plugins-workspace
that referenced
this pull request
Dec 5, 2023
* Do not use rfd 0.12.1 PolyMeilex/rfd#152 conflicts with the way tauri uses it. > Yeah, this is a decent solution, not much else we can do about this global state bs on C side. > > This will obviously blow up as soon as someone has other code that also uses GTK, but let's ignore that for now, as I want to get rid of GTK backend one day anyway (#66). Yes, Tauri is other code that also uses GTK, and it does, indeed, blow up. The best way around this is to stop using rfd entirely (they're planning to drop the GTK backend, which will probably break since the XDG Portal API doesn't cover message dialogs). * Update dialog-pin-rfd.md --------- Co-authored-by: Fabian-Lars <[email protected]>
tauri-bot
pushed a commit
to tauri-apps/tauri-plugin-dialog
that referenced
this pull request
Dec 5, 2023
* Do not use rfd 0.12.1 PolyMeilex/rfd#152 conflicts with the way tauri uses it. > Yeah, this is a decent solution, not much else we can do about this global state bs on C side. > > This will obviously blow up as soon as someone has other code that also uses GTK, but let's ignore that for now, as I want to get rid of GTK backend one day anyway (#66). Yes, Tauri is other code that also uses GTK, and it does, indeed, blow up. The best way around this is to stop using rfd entirely (they're planning to drop the GTK backend, which will probably break since the XDG Portal API doesn't cover message dialogs). * Update dialog-pin-rfd.md --------- Co-authored-by: Fabian-Lars <[email protected]> Committed via a GitHub action: https://github.com/tauri-apps/plugins-workspace/actions/runs/7105035118 Co-authored-by: FabianLars <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When investigating #150 more deeply, I noticed that the GTK documentation seems to indicate that all GTK functions must only be called on the thread that called gtk_init(). The existing code does ensure that only one thread accesses GTK at a time, but the documentation seems to suggest that once a thread calls gtk_init, all calls to GTK must go through that thread:
To facilitate that, this PR changes the GTK dialog code to spin up a thread and initialize GTK on it, keeping it alive for the lifetime of the program. It's a bit unfortunate that we have to keep it around forever, but the GTK documentation seems to indicate that once you call gtk_init on a thread, you're stuck with that thread.