Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/mobile: do away with app.Main boilerplate #13988

Closed
gordonklaus opened this issue Jan 17, 2016 · 7 comments

Comments

Projects
None yet
6 participants
@gordonklaus
Copy link
Contributor

commented Jan 17, 2016

The purpose of app.Main is to ensure that main.main runs on "the main thread" on certain platforms. Couldn't this also be achieved by having gomobile inject initialization code into the code it is compiling?

It's just a shame that every mobile app currently needs an extra level of indentation in func main. It adds unnecessary complexity, makes you wonder "what kinds of operations can I do in main vs in the app.Main callback?". It makes mobile apps feel like second-class citizens.

@ianlancetaylor ianlancetaylor added this to the Unreleased milestone Jan 18, 2016

@rakyll

This comment has been minimized.

Copy link
Member

commented Jan 19, 2016

I proposed that we should minify the verbosity in the main package a while ago as well.

main.main is invoked lazily on mobile platforms, it is more trivial to remove the boilerplate. I am not sure how it could effect the initialization on "desktop" mobile apps.

/cc @crawshaw @hyangah

@rakyll

This comment has been minimized.

Copy link
Member

commented Jan 19, 2016

And @nigeltao.

@crawshaw

This comment has been minimized.

Copy link
Contributor

commented Jan 20, 2016

The problem is OS X, where Cocoa wants to use the first thread acquired by the process for its event pump. If you have a way to make "go build" work on OS X without app.Main, let's remove it, but it is not a feature I want to lose.

@crawshaw crawshaw closed this Jan 20, 2016

@gordonklaus

This comment has been minimized.

Copy link
Contributor Author

commented Jan 20, 2016

@crawshaw Is it just OS X, not also iOS?

Could it be as simple as automatically injecting this file into the build?

package main

import "runtime"

func init() {
    runtime.LockOSThread()
}
@mdempsky

This comment has been minimized.

Copy link
Member

commented Jan 20, 2016

@gordonklaus One potential flaw with that solution is runtime.LockOSThread is not recursive (at least currently). So if the main goroutine then calls some function that uses runtime.LockOSThread() + runtime.UnlockOSThread(), the OS thread will end up unlocked.

@crawshaw

This comment has been minimized.

Copy link
Contributor

commented Jan 21, 2016

@gordonklaus that's not enough, on OS X you need that code and you need to call [NSApp run] from that thread. That call blocks forever, so it needs to be inside the main function. Hence app.Main.

@gordonklaus

This comment has been minimized.

Copy link
Contributor Author

commented Jan 21, 2016

@crawshaw I see.

I think app.Main can still be avoided. It will just require some source manipulation, rewriting main.main. Maybe I'll take a crack at it tomorrow. Any advice is more than welcome 😄

@golang golang locked and limited conversation to collaborators Jan 23, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.