macOS requires all GUI code to be on the first thread created by the OS. The Go runtime moves goroutines between OS threads unless runtime.LockOSThread() is called. But there is no formally documented way to ensure that a goroutine is locked to the first OS thread, as opposed to the thread the goroutine happens to be running on at the moment.
Go currently does allow this, though: call runtime.LockOSThread() from init(). Of course, there are catches that I will need to document to be able to do this and make sure it doesn't fail, and Go 1.10's change to make runtime.LockOSThread() nested will fix some of them. And the biggest issue is that this isn't really documented yet, meaning I didn't feel comfortable relying on it. Other similar packages (like shiny) did, so...
I've filed an issue on Go asking for this feature to be documented — golang/go#23112. However, fixing this in package ui is not contingent on that issue being closed. package ui documentation might be.
The other benefit to this is that we won't need undocumented API calls or mach_override hacks.
You can monitor this issue to see when I have implemented the necessary fixes. IDK if it will require an API change or not.
macOS requires all GUI code to be on the first thread created by the OS. The Go runtime moves goroutines between OS threads unless
runtime.LockOSThread()is called. But there is no formally documented way to ensure that a goroutine is locked to the first OS thread, as opposed to the thread the goroutine happens to be running on at the moment.Go currently does allow this, though: call
runtime.LockOSThread()frominit(). Of course, there are catches that I will need to document to be able to do this and make sure it doesn't fail, and Go 1.10's change to makeruntime.LockOSThread()nested will fix some of them. And the biggest issue is that this isn't really documented yet, meaning I didn't feel comfortable relying on it. Other similar packages (like shiny) did, so...I've filed an issue on Go asking for this feature to be documented — golang/go#23112. However, fixing this in package ui is not contingent on that issue being closed. package ui documentation might be.
The other benefit to this is that we won't need undocumented API calls or mach_override hacks.
You can monitor this issue to see when I have implemented the necessary fixes. IDK if it will require an API change or not.