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

Closed
cortex opened this issue Oct 3, 2015 · 8 comments
Closed

x/mobile/app: basic app doesn't exit when window is closed #12828

cortex opened this issue Oct 3, 2015 · 8 comments
Labels
FrozenDueToAge mobile Android, iOS, and x/mobile
Milestone

Comments

@cortex
Copy link

cortex 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
Copy link

jhsx 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
Copy link
Contributor

rakyll commented Oct 3, 2015

/cc @crawshaw

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

db47h 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
Copy link

db47h 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
Copy link
Member

@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
Copy link

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

@gopherbot
Copy link

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

@gopherbot gopherbot added the mobile Android, iOS, and x/mobile label Jul 20, 2017
@changkun
Copy link
Member

Apps can exist properly today, except windows (see #49499). Close.

@golang golang locked and limited conversation to collaborators Mar 21, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge mobile Android, iOS, and x/mobile
Projects
None yet
Development

No branches or pull requests

7 participants