You can definitely run the event loop for a process on a thread other than main. The main thread is the thread created by the OS to begin running the process - the UI thread is the one that initializes the Windowing system. Some OSs even support multiple UI threads (see https://docs.microsoft.com/en-us/cpp/parallel/multithreading-creating-user-interface-threads?view=vs-2019 <https://docs.microsoft.com/en-us/cpp/parallel/multithreading-creating-user-interface-threads?view=vs-2019>)
Go doesn’t do any Windowing system initialization by default - the main thread in Go (at least according to the referenced library) is the one that called the package init() - which may not even be the OS main thread since according to the Go docs "Package initialization—variable initialization and the invocation of init functions—happens in a single goroutine, sequentially, one package at a time.” - which makes no claim that this Go routine is running on the “main” OS thread. Whatever thread you use to initialize GLFW is the UI thread (or main for GLFW). This is pretty standard across windowing/graphics systems. > On Jan 3, 2020, at 4:02 PM, bucha...@gmail.com wrote: > > I'm pretty sure the OS event loop is required to be on the main thread. > > From the GLFW docs for glfwPollEvents: > "This function must only be called from the main thread." > > From the SDL docs for SDL_WaitEvent: > "you can only call this function in the thread that initialized the video > subsystem." > > > On Friday, January 3, 2020 at 1:58:29 PM UTC-8, Robert Engels wrote: > Even if you could I don’t think you would want to do it this way. > > Have a go routine sleep on a channel. Post to the channel from the native > code. > > Let your command loop run on any thread and synchronize via a channel the > calls to/from native. > > The os event loop doesn’t need to run on main - it just needs to be locked to > a thread - use a native thread - and post the os events to a channel. > > Probably easiest to export a simple Go postToEventChannel() and have the > native use this. > >> On Jan 3, 2020, at 2:18 PM, buch...@gmail.com <javascript:> wrote: >> >> >> I've been getting by with a version of this that sends commands (closures) >> to a loop on the main thread: >> https://github.com/buchanae/ink/blob/2af8781a960a0351b6b6b7ca23d81ae5c43535ec/win/window.go#L55 >> >> <https://github.com/buchanae/ink/blob/2af8781a960a0351b6b6b7ca23d81ae5c43535ec/win/window.go#L55> >> >> And here is where it pops those commands, and also integrates with the OS >> event loop: >> https://github.com/buchanae/ink/blob/2af8781a960a0351b6b6b7ca23d81ae5c43535ec/win/window.go#L163 >> >> <https://github.com/buchanae/ink/blob/2af8781a960a0351b6b6b7ca23d81ae5c43535ec/win/window.go#L163> >> >> But, I'm still not satisfied. The solution ties together the scheduling (and >> code) of two separate event loops. In particular, I've found that my >> commands are delayed ~10ms – I think sdl.WaitEvent might be rate limited. >> >> What I really want is for the two event loops (OS event loop vs app command >> loop) to be in two separate goroutines, both running on the main thread. >> That way, the OS event loop can react to infrequent window events (mouse >> clicks, etc) without burning lots of CPU, while my app command loop can >> react to commands instantly. >> >> Does that make sense? Is this possible to implement without requiring a >> change to the Go runtime? Is it possible to change the Go runtime to allow >> multiple goroutines to be scheduled only to the main thread? >> >> Thanks. >> >> -- >> 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 golan...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/e4e3a04d-0f76-4baf-9760-9992ef38d51f%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/e4e3a04d-0f76-4baf-9760-9992ef38d51f%40googlegroups.com?utm_medium=email&utm_source=footer>. > > > -- > 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 > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/cbbca787-1dec-4729-b91f-25a7b5725d80%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/cbbca787-1dec-4729-b91f-25a7b5725d80%40googlegroups.com?utm_medium=email&utm_source=footer>. -- 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/417C1A53-4A6B-42E7-BC02-BB0F7875B379%40ix.netcom.com.
