Whether the UI thread is on the main thread or a separate thread, a single
UI thread needs to process events from two sources: the OS window and from
my application. Having one loop process both sources (without support from
the Go runtime scheduler) is the part I'm struggling with.
My latest iteration is something like:
for {
// PollEvent doesn't block/sleep
for ev := sdl.PollEvent(); ev != nil; ev = sdl.PollEvent {
// handle OS window events
}
select {
case cmd := <-app.commands:
// process application command
cmd()
case <-time.After(10*time.Millisecond):
// only wait 10ms for application commands
}
}
This is an improvement, but I'd still prefer help from the Go runtime. If
the runtime supported locking two goroutines to the UI thread, I could
split this loop into two separate loops and remove the time.After, I
*think*.
On Friday, January 3, 2020 at 2:59:42 PM UTC-8, robert engels wrote:
>
> 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
> )
>
> 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, buch...@gmail.com <javascript:> 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 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
>>
>> 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
>>
>> 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.
>> 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 golan...@googlegroups.com <javascript:>.
> 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/6a32824e-cd50-4fe6-9411-3ecb975718d5%40googlegroups.com.
