Also, even simpler - just remove the time.Atfter case() and use a default: -
but the problem is you will spin a single thread at 100% cpu - you really need
to use a blocking sdl.WaitEvent()
> On Jan 3, 2020, at 6:04 PM, robert engels wrote:
>
> You only need a single thread locked to the UI th
In reviewing your comments so more, I think you may be having trouble because
you are initializing the graphics UI in the init() method. I think that is
going to make things difficult. You are better off adding a StartUI() - which
spawns a Go routine that handles all UI communicates (you could s
You only need a single thread locked to the UI thread.
Use one Go routine locked to the UI thread. Put events onto a channel.
Have another Go routine read from the channel, and the app command channel
using select.
> On Jan 3, 2020, at 5:28 PM, bucha...@gmail.com wrote:
>
> Whether the UI th
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 i
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.c
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."
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
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://g
See also:
https://github.com/faiface/mainthread
--
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
Yep. My understanding of locking the OS thread from an init() was wrong. I
think I have it working now. Thanks guys!
On Tue, Dec 17, 2019, at 9:37 AM, Ian Davis wrote:
>
>
> On Sat, 14 Dec 2019, at 7:51 PM, bucha...@gmail.com wrote:
>> If I understand correctly, that would prevent me from start
On Sat, 14 Dec 2019, at 7:51 PM, bucha...@gmail.com wrote:
> If I understand correctly, that would prevent me from starting any other
> goroutines. The following program deadlocks:
I doesn't prevent you starting other goroutines but you need to ensure that all
calls to the OpenGL context are p
On Sat, Dec 14, 2019 at 11:51 AM wrote:
>
> If I understand correctly, that would prevent me from starting any other
> goroutines. The following program deadlocks:
That turns out not to be the case. You can start other goroutines.
Your program deadlocks because you called time.After when you me
I found some existing discussion on this topic:
https://github.com/golang/go/issues/14163
Not sure I fully understand the reasoning there. If there is a better way
forward that doesn't involve adding a controversial function to the
scheduling package, I'm all ears.
On Saturday, December 14, 2
Would it be reasonable to make a Go proposal that adds something like
runtime.MainThread(), which would cause the calling goroutine to only ever
be scheduled on the main thread? Unlike runtime.LockOSThread, it would not
need to prevent other goroutines from running on the main thread (I think).
If I understand correctly, that would prevent me from starting any other
goroutines. The following program deadlocks:
package main
import (
"log"
"runtime"
"time"
)
func init() {
runtime.LockOSThread()
}
func main() {
go func() {
for range time.After(time.Second) {
On Sat, Dec 14, 2019 at 11:31 AM wrote:
>
> I'd really love to get that LockOSThread call out of the main function and
> hide it away inside a library along with the other internal implementation
> details. Is that possible? As far as I can tell, it's not possible to ensure
> that a goroutine r
I've been experimenting with graphics programming using go+sdl2 for awhile
now. I've always been uncertain how to deal with locking a goroutine to the
main thread. MacOS requires interactions with the OS window to come from
the main thread.
So far, I have something like this (pseudocode):
fun
17 matches
Mail list logo
