Making sure miqt is safe with Go routines

[emad-elsaid]

While using Miqt for a new project I noticed a pattern I would like to demo here. I would like some help planning how to avoid falling into it.

• Any call to Miqt functions that execute a Cgo binding has to be executed in the main thread.
• Miqt offers mainthread.Wait to wrap logic that executes outside of the main thread to run it safely.
• This means to make sure the whole program is safe the developer has to wrap every part that uses Miqt in mainthread.Wait
• Not wrapping any function will increase the risk calling the function from another Go routine (which is common in Go)
• Especially that sharing the thread with Qt means waiting for a little slow Go function will freeze the UI?

So now I noticed that every function that mentions qt6 package or any struct that's based on it has to be wrapped in mainthread.Wait otherwise the program just panics. Or run my whole program in one Thread which strips Go from it's most useful feature: Goroutines.

What do you recommend to do in this case? any moderately complex program will have many execution paths that may or may not be running from the mainthread and wrapping every part of the logic in wait will make it look unnecessarily complex. I'm also not sure what happens if wait is called from the main thread. I guess the program just hangs?

Edit: Yes calling mainthread.Wait twice will hang the program. This means there is no gurantee one execution path can call it then continue to call another function that will call wait again and the program will stop responding.

Edit2: I think I can avoid that by serializing the changes to the UI through a Go channel (chan func()) and have a function consuming from the channel and executing the function with mainthread.Wait.

Edit3: This solution worked. with one caveat. when trying to enqueue a UI change from another UI change. the channel will block as the loop consuming is trying to push to the channel. the solution is to make it buffered channel to allow pushing without blocking in nested UI changes calls

import "github.com/mappu/miqt/qt6/mainthread"

// uiChanges holds functions that will change the memory. enqueuing a new UIChange while executing a UI change will halt if the channel is unbuffered.
// So the solution is to give it a size the represents the maximum number of nested UIChanges calls that could happen in the program.
// The number here is arbitrary, but it should be enough to not block the UI thread.
var uiChanges = make(chan func(), 1000)

func UIChanges(f func()) {
	uiChanges <- f
}

func ApplyUIChanges() {
	for f := range uiChanges {
		mainthread.Wait(f)
	}
}

func init() {
	go ApplyUIChanges()
}

[emad-elsaid]

@mappu I implemented a solution that solved it for my case. would you please check it, maybe it's useful enough to include it in the mainthread package.

[mappu]

I'm glad you were able to solve the problem. 😄

When you call UIChange(func() { ... }) the calling thread no longer waits for the UI change to complete, avoiding the deadlock. This is the same behaviour as mainthread.Start(), of which mainthread.Wait() is a wrapper around it. Can you possibly use mainthread.Start()?

[mappu]

Your queue of 1000 events here is a great design.

Qt has an internal queue already, almost identical to this: the main thread really spends all its time blocked in QApplication::exec() waiting to run all the event functions passed to it by every widget on the main thread, just like the ApplyUIChanges() worker.

mainthread.Start() queues a new event directly into this main thread's event loop via Qt::QueuedConnection.

[emad-elsaid]

I tried mainthread.Start() and it worked even when nested. I guess I don't need the extra queue I reated then. thank you

[mappu]

any moderately complex program will have many execution paths that may or may not be running from the mainthread

Goroutines are really great, but they do not magically prevent data races. If you have multiple goroutines all updating the same shared variable, you still must either (A) protect it with a mutex or else (B) serialize access into a single thread (like Qt's thread affinity).

Therefore, even in Go, you still must somewhat know what thread your code is running on.

Architecting a large Qt/C++ program to avoid these issues is, I think, a skill that comes with practice. It can help a lot to split a function into its UI-part and logic-part. It's also important not to block the main UI thread as this can cause the UI to appear unresponsive.

C++ has some tricks in its "favour" - (1) signal/slots can also safely cross QThread boundaries; and (2) making a QThread is cumbersome so you don't do it often, and when you do, usually know exactly what thread your function is running on.