Open andy128k opened 1 year ago
Seems the problem comes from https://github.com/gtk-rs/gtk4-rs/blob/master/gtk4/src/rt.rs#L99-L107 so someone with access to a macos machine would have to debug this.
Recently released Rust 1.67 made things somehow worse. Now new threads are spawned for every test.
This happened to be an old issue. This stackoverflow question is almost 6 years old. It advises to not to use libtest
harness and write tests out of source tree. E.g. fltk-rs
follows this and their tests look like this.
N.B. I've also found a useful article with details how to organize such tests.
So, #[gtk::test]
macro makes tests run in the same thread, but this thread is never a main one. That works on Linux and Windows but does not work on macos. I don't see how any macro may solve this given that a main thread is used by libtest
itself.
This seems pretty bad, won't this interfere with testing in every single other GUI crate that binds anything related to appkit? Do we know exactly what functions have to be called on the main thread?
I wonder if we can workaround it for now by making CI use a gtk build with the x11 or broadway backend, if that will avoid calling any appkit functions?
@jf2048 something i tried to do here is to make use of https://developer.apple.com/documentation/dispatch/1453123-dispatch_sync_f, but as i don't have access to a macos and the CI being slow, it was impossible to implement....
I just learned that there is actually a wrapper for this macOS dispatch thing. We can use http://sasheldon.com/rust-objc/dispatch/struct.Queue.html#method.sync to achieve what we want I believe. I added it to my to-do list
Bug description
Minimal example https://github.com/andy128k/test-gtk-rs-osx Successful build on Linux https://github.com/andy128k/test-gtk-rs-osx/actions/runs/3828477828/jobs/6514110530 Failure on macos https://github.com/andy128k/test-gtk-rs-osx/actions/runs/3828477834/jobs/6514110710
Backtrace