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.
On Sat, Sep 30, 2023 at 11:36 PM Kurtis Rader <kra...@skepticism.us> wrote: > On Sat, Sep 30, 2023 at 12:23 AM TheDiveO <harald.albre...@gmx.net> wrote: > >> Did you explicitly lock the initial OS thread, aka M0, to the >> main/initial go routine by calling runtime.LockOSThread() from main or an >> init func? I suspect you were lucky in the past, but I might be wrong. >> > > No, I did not explicitly lock the initial thread using > runtime.LockOSThread(). However, I have run the program hundreds of > times, and for tens of hours, while working on it and not once, before > introducing signal.NotifyContext()did I see an instance of the gocv > package complaining about the thread it was running on not being the main > thread. It is certainly possible I have simply been lucky but that seems > unlikely since it fails every single time I run it when using > signal.NotifyContext(). > > -- > Kurtis Rader > Caretaker of the exceptional canines Junior and Hank > -- 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%3DD8r733XsHoZ1jsuCaH2cY%3Ds9179yuWGOPkJf5qL6a7m6A%40mail.gmail.com.
