hi,

(apologies for the barrage of emails)

IIUC, we currently need to run the "graphics" event loop on the main
OS-thread because that's what the underlying C-libraries and/or the
drivers they talk to are using as a programming model.

so we have this whole runtime.LockOSThread + goroutines-serving
callbacks scaffolding.
(the same is done, if I am not mistaken, for, e.g., debugging and ptrace)

from a developer point of view, it's fine, I guess, and once you
understand the underlying constraints, that makes sense.
but from a user point of view, or a consumer of such a package, it's a
bit of a pain: the user's main need to be modified and parts of its
logical flow as well.

so, here is my question after this rather lengthy introduction:
did somebody ever floated the idea of having yet another "//go:xyz"
magical comment decoration be understood by the Go toolchain to be able
to not bleed too much implementation details?

ideally, we could have something like:

package app

//go:lock-main-thread
func Main() { ... }


and have user code do just:

package main

import "gioui.org/app"

func init() {
    go app.Main()
}

and be done with it.
this would dramatically simplify user code.
(this would of course be done at the price of complicating a bit more
Go's runtime, or at least Go idioms)

what do you think? was this already proposed to Go core?

-s

On Thu, Dec 10, 2020 at 08:04:14PM +0000, Sebastien Binet wrote:
> hi,
> 
> (apologies for the barrage of emails)
> 
> IIUC, we currently need to run the "graphics" event loop on the main
> OS-thread because that's what the underlying C-libraries and/or the
> drivers they talk to are using as a programming model.
> 
> so we have this whole runtime.LockOSThread + goroutines-serving
> callbacks scaffolding.
> (the same is done, if I am not mistaken, for, e.g., debugging and ptrace)
> 
> from a developer point of view, it's fine, I guess, and once you
> understand the underlying constraints, that makes sense.
> but from a user point of view, or a consumer of such a package, it's a
> bit of a pain: the user's main need to be modified and parts of its
> logical flow as well.
> 
> so, here is my question after this rather lengthy introduction:
> did somebody ever floated the idea of having yet another "//go:xyz"
> magical comment decoration be understood by the Go toolchain to be able
> to not bleed too much implementation details?
> 
> ideally, we could have something like:
> 
> package app
> 
> //go:lock-main-thread
> func Main() { ... }
> 
> 
> and have user code do just:
> 
> package main
> 
> import "gioui.org/app"
> 
> func init() {
>     go app.Main()
> }
> 
> and be done with it.
> this would dramatically simplify user code.
> (this would of course be done at the price of complicating a bit more
> Go's runtime, or at least Go idioms)
> 
> what do you think? was this already proposed to Go core?
> 
> -s
> 
> 

What happens if Main gets called and there already is a goroutine locked to
the main thread?

Doesn't locking os thread in init serve the same purpose?

    func init() { runtime.LockOSThread() }

On Thu, Dec 10, 2020 at 10:04 PM Sebastien Binet <s@sbinet.org> wrote:
>
> hi,
>
> (apologies for the barrage of emails)
>
> IIUC, we currently need to run the "graphics" event loop on the main
> OS-thread because that's what the underlying C-libraries and/or the
> drivers they talk to are using as a programming model.
>
> so we have this whole runtime.LockOSThread + goroutines-serving
> callbacks scaffolding.
> (the same is done, if I am not mistaken, for, e.g., debugging and ptrace)
>
> from a developer point of view, it's fine, I guess, and once you
> understand the underlying constraints, that makes sense.
> but from a user point of view, or a consumer of such a package, it's a
> bit of a pain: the user's main need to be modified and parts of its
> logical flow as well.
>
> so, here is my question after this rather lengthy introduction:
> did somebody ever floated the idea of having yet another "//go:xyz"
> magical comment decoration be understood by the Go toolchain to be able
> to not bleed too much implementation details?
>
> ideally, we could have something like:
>
> package app
>
> //go:lock-main-thread
> func Main() { ... }
>
>
> and have user code do just:
>
> package main
>
> import "gioui.org/app"
>
> func init() {
>     go app.Main()
> }
>
> and be done with it.
> this would dramatically simplify user code.
> (this would of course be done at the price of complicating a bit more
> Go's runtime, or at least Go idioms)
>
> what do you think? was this already proposed to Go core?
>
> -s
>
>

On Thu Dec 10, 2020 at 22:24, Egon Elbre wrote:
> Doesn't locking os thread in init serve the same purpose?
>
>     func init() { runtime.LockOSThread() }
>

Yes, and that's what Gio does on the platforms that need it:

https://git.sr.ht/~eliasnaur/gio/tree/main/internal/rendertest/util_test.go#L190

FWIW, I don't think Go should make special provisions for what I
consider a broken threading model. Linux has never had that "main
thread" requirement, and Windows only binds a window to the current
thread, not some global main thread.

Elias