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 -- 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/CAOyqgcVdCDvnMk1a9OZKY9wokREmyVjGMpOiU5wUA19s%3D86eHA%40mail.gmail.com.
