Thank you to Ian and TheDiveO. I don't understand why functions like
gocv.io/x/gocv.NewWindow() have to run on the initial OS thread (at least
on macOS). But adding this to my main package stopped the gocv package from
panicking:
func init() {
runtime.LockOSThread()
}
Is there some reason that locking the main() function to the initial thread
isn't the default?
On Mon, Oct 2, 2023 at 5:05 PM Ian Lance Taylor <i...@golang.org> wrote:
> On Sat, Sep 30, 2023 at 11:56 PM Kurtis Rader <kra...@skepticism.us>
> wrote:
> >
> > And having said that I just tested using runtime.LockOSThread() and it
> does allow me to use the more obvious, natural, way to write the main()
> function. Which still begs the question of why calling
> signal.NotifyContext() causes subsequent code to run on a different OS
> thread. If nothing else this seems like a side-effect that should be
> documented; along with the recommendation of using runtime.LockOSThread()
> to avoid that side-effect.
>
> Goroutines are multiplexed onto operating system threads. A goroutine
> that does not call runtime.LockOSThread can move to a different
> operating system thread at (almost) any time. The goroutine scheduler
> can and does move goroutines between threads without regard to what
> those goroutines are doing. I don't know why this is happening
> particularly for signal.NotifyContext, but whatever the reason is,
> it's unlikely to be interesting. If your code cares about which
> operating system thread it runs on, it must use runtime.LockOSThread.
>
> Ian
>
--
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD__QffcCUPxDDOEgNEz0gBg4%3DAffBzNnJW04o29Ax2Vuw%40mail.gmail.com.
