If I understand correctly, this approach is working today:

func init() {
        // Run main on the startup thread to satisfy the requirement
        // that Main runs on that thread.
	runtime.LockOSThread()
}

Would an alternative be to add // Note that init functions run on the startup thread; the main function runs on the startup thread if LockOSThread is called during initialization. to LockOSThread to add a compatibility guarantee?

In other words, it isn't quite clear to me what the concrete benefit of LockMainOSThread is. Is it that packages that need to do things on the main thread don't need to tell users to do something specific in main?

What happens if two different goroutines call LockMainOSThread?

cc @golang/runtime

If I understand correctly, this approach is working today:

func init() {
        // Run main on the startup thread to satisfy the requirement
        // that Main runs on that thread.
	runtime.LockOSThread()
}

It works in the sense that every user of, say, AppKit or UIKit need to give up the main thread through contortions that a library is unable to hide. For a Gio user, it's the difference between

import "gioui.org/app"

func main() {
    go func() {
        w := new(app.Window)
        for {
             e := w.NextEvent()
             // Respond to e, usually by redrawing window content.
        }
    }()
    app.Main()
}

and

import "gioui.org/app"

func main() {
        w := new(app.Window)
        for {
             e := w.NextEvent()
             // Respond to e, usually by redrawing window content.
        }
}

Would an alternative be to add // Note that init functions run on the startup thread; the main function runs on the startup thread if LockOSThread is called during initialization. to LockOSThread to add a compatibility guarantee?

This is already documented as a guarantee by runtime.LockOSThread.

In other words, it isn't quite clear to me what the concrete benefit of LockMainOSThread is. Is it that packages that need to do things on the main thread don't need to tell users to do something specific in main?

Yes.

What happens if two different goroutines call LockMainOSThread?

One (or both) block, waiting for the main thread to become available.

I've filed an less flexible but perhaps simpler alternative: #64777. Both proposals now also mention the syscall option to avoid polluting package runtime.

Anecdotally, and without bearing on the proposal, I just want to mention that Go is unique to be able to offer this feature by virtue of goroutines. Other GUI libraries either revert to a callback design or live with the hacky workarounds. For example, a prominent Rust library first considered using user mode context switching (similar to how goroutines can switch OS thread), but eventually ended up inverting their control flow to a callback design.

I actually prefer the principle of this proposal over the callback alternative in #64777. Part of the philosophy of goroutines is that you should be able to write straight-line (blocking) code and the language implementation will hide the details of context management and control flow. #64777 feels more akin to async/promise-style programming.

That said, LockMainOSThread certainly has some issues:

• Implementation-wise, we don't currently have any mechanism to say "this computation must run on this specific thread", which I think turns out to be quite different from LockOSThread's "this computation must continue to run on its current thread." It's not immediately obvious to me that there's a simple way to add this capability.
• It doesn't compose well. If two goroutines both use LockMainOSThread and one of them makes a blocking system call, the other one is just stuck until that returns. This could very easily lead to deadlocks. (In a sense, this problem is inherited from these various facilities that require things to be done on the main thread. That requirement itself doesn't compose.)

I see you've spelled out some clever restrictions on #64777's RunOnMainThread that work around these issues, but I also feel like they do so by exposing implementation limitations and leaning into non-composability. :)

I actually prefer the principle of this proposal over the callback alternative in #64777. Part of the philosophy of goroutines is that you should be able to write straight-line (blocking) code and the language implementation will hide the details of context management and control flow. #64777 feels more akin to async/promise-style programming.

That said, LockMainOSThread certainly has some issues:

• It doesn't compose well. If two goroutines both use LockMainOSThread and one of them makes a blocking system call, the other one is just stuck until that returns. This could very easily lead to deadlocks. (In a sense, this problem is inherited from these various facilities that require things to be done on the main thread. That requirement itself doesn't compose.)

It's hopeless to design for more than one package being able to use the main thread, without explicit coordination. In fact, my motivating use-case is a native call that never returns.

That leaves the behaviour when more than one goroutine calls LockMainOSThread. I'm proposing the loser block, which as you point out leads to a likely deadlock. How about panicing, similar to the "deadlock, all goroutines are asleep" condition?

• Implementation-wise, we don't currently have any mechanism to say "this computation must run on this specific thread", which I think turns out to be quite different from LockOSThread's "this computation must continue to run on its current thread." It's not immediately obvious to me that there's a simple way to add this capability.

Assuming a losing LockMainOSThread panics, I imagine implementation becomes easier because a goroutine will never be parked with in a special state (e.g. waitingForMainThread). Something like

• Check if current thread is main. If so, we're done.
• Otherwise reschedule similar to a very short time.Sleep, but search for a particular m instead of any m.
• If the main thread is busy, continue scheduling as a normal goroutine, but initiate a panic.

This implementation requires the Go runtime to never schedule anything on the main thread, thus wasting a thread in the general case. I don't know the complexity of forcing a (non-syscalling) goroutine off a thread.

I'm no runtime export, so I apologize if the above is hopelessly naïve.

Assuming a losing LockMainOSThread panics, I imagine implementation becomes easier because a goroutine will never be parked with in a special state (e.g. waitingForMainThread). Something like

Check if current thread is main. If so, we're done.
Otherwise reschedule similar to a very short time.Sleep, but search for a particular m instead of any m.
If the main thread is busy, continue scheduling as a normal goroutine, but initiate a panic.

Goroutines preempt one specific thread ^ It looks much simpler/clear to keep things in main(), if certain things must happen in main thread.

Another use-case came to my attention: because Windows services require the main thread, every Go package for running a Go program as a Windows service expose contorted callback APIs.

Examples: https://pkg.go.dev/golang.org/x/sys/windows/svc#Run, https://pkg.go.dev/github.com/kardianos/service#Service (see its Run documentation), https://pkg.go.dev/github.com/judwhite/go-svc#Run.

In fact, none of the various Runs document the main goroutine requirement! I learned this the hard way, trying to debug why go svc.Run() didn't work.

I believe with this proposal, or a variant, you'll be able to expose a Windows service with a straightforward, non-blocking

func main() {
    svc.SetupService()
    // do rest of setup: open database connections, start HTTP listener etc.
}

Or, if you're interested in service events:

func main() {
    go func() {
        evts, err := svc.RunService()
        for {
             e, ok := evts.Event()
             // handle and respond to e.
        }
    }()
    // do rest of setup: open database connections, start HTTP listener etc.
}

How would several libraries utilizing this functionality coordinate?

In the current state (LockOSThread from init, callbacks) they can because it's up to a user to structure a single goroutine to call several libraries.

The only combination that comes to mind immediately is a debugger under Darwin, where both ptrace and AppKit want to be called from main thread, but I'm pretty sure other examples eventually will transpire.

RunOnMainThread seems more composable than locking the thread to one library's goroutine.

How would several libraries utilizing this functionality coordinate?

Like today: explicitly.

In the current state (LockOSThread from init, callbacks) they can because it's up to a user to structure a single goroutine to call several libraries.

Not so for AppKit, UIKit nor Windows services: they all require the main thread and never relinquish control of it. The best you can do is to ask nicely for a callback.

This proposal is primarily for enabling Go packages to expose natural Go APIs for main-thread greedy platform facilities.

The only combination that comes to mind immediately is a debugger under Darwin, where both ptrace and AppKit want to be called from main thread, but I'm pretty sure other examples eventually will transpire.

RunOnMainThread seems more composable than locking the thread to one library's goroutine.

@dottedmag you may like the #64777 (comment) variant better. It's currently my favorite.