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/app: basic app doesn't exit when window is closed #12828

Open
cortex opened this issue Oct 3, 2015 · 7 comments

Comments

@cortex
Copy link

commented Oct 3, 2015

I tried running the basic example with:
go install golang.org/x/mobile/example/basic && basic
When clicking the close-window button, the application does not exit. It does stop repainting however, and appears hung. I tried inserting some log lines for lifetime events, but there doesn't seem to be any event sent when the window is closed, but the paint.Event stops.

This is on Arch Linux running Gnome 3.16.

@jhsx

This comment has been minimized.

Copy link

commented Oct 3, 2015

This is happening on Mac OS X also.

@rakyll rakyll changed the title x/mobile: Basic app doesn't exit when window is closed x/mobile/app: basic app doesn't exit when window is closed Oct 3, 2015

@rakyll

This comment has been minimized.

Copy link
Member

commented Oct 3, 2015

/cc @crawshaw

@rakyll rakyll added this to the Unreleased milestone Oct 3, 2015

@db47h

This comment has been minimized.

Copy link

commented Nov 9, 2015

On X11, closing the window triggers onStop() which sends a lifecycle event then a stopPumping{} event.

In the app.pump() loop, the lifecycle event gets in the event buffer, then on the next iteration stopPumping{} is received, discarding the input event channel, but the lifecycle event has not been sent out yet and remains in the buffer. What happens next is that the application's main loop sits in a.Send(paine.Event{}), trying to send to the input event channel, which the pump() loop does not read anymore. As for pump(), it blocks forever waiting to send out that last lifecycle event.

A possible fix could be to actually close eventsIn upon receiving stopPumping{}, and perform all internal event sending via app.Send() with modifications to discard events should the channel be closed.

Edit: possibly related, if the example's main loop does not send paint events itself (suppose a GUI app that does no animations), no other events are received, dead lock. Haven't investigated this yet, but this is to keep in mind when fixing.

@db47h

This comment has been minimized.

Copy link

commented Nov 9, 2015

I have a much simpler working fix that uses a boolean done flag in pump() that is set to true when a stopPumping{} is received. If done is true, incoming events are just ignored, thus keeping both input and output event channels alive. Should I submit a CL with this?

@crawshaw

This comment has been minimized.

Copy link
Contributor

commented Nov 16, 2015

@db47h: I'd like to see if we could sort this out in the shiny version of closing the events channel first, and then copy that code into x/mobile.

@gopherbot

This comment has been minimized.

Copy link

commented Nov 16, 2015

CL https://golang.org/cl/16960 mentions this issue.

@gopherbot

This comment has been minimized.

Copy link

commented Nov 19, 2015

CL https://golang.org/cl/17055 mentions this issue.

@gopherbot gopherbot added the mobile label Jul 20, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.