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

panic! on overlapping calls to poll_events and run_forever #136

Closed

Conversation

mitchmindtree
Copy link
Contributor

This is a follow up to #126 and addresses the need to panic! if a callback is given inside another callback.

@tomaka this also disallows overlapping calls to poll_events and run_forever across threads - is this OK? Or is this something that should be supported?

@tomaka
Copy link
Contributor

tomaka commented Feb 12, 2017

this also disallows overlapping calls to poll_events and run_forever across threads - is this OK? Or is this something that should be supported?

Unfortunately that's not acceptable.
I didn't think of this problem when I wrote my comment in #126.
Maybe it's better to leave that to the backend and add tests instead, I'm not sure.

@mitchmindtree
Copy link
Contributor Author

I guess it could be OK to leave this to the backends to decide, as long as it was well documented in the poll_events and run_forever methods.

On the other hand, a user using winit in order to remain portable across backends may become frustrated if they write their application on e.g. Linux expecting to be able to poll events from any thread, only to discover that macOS events must be polled from the main thread when they begin testing on other platforms. Maybe this would be avoided by documentation though.

What is the use-case for allowing simultaneous event polling from separate threads? In most cases I'd imagine events need to be handled in order anyway (e.g. mouse movement, window resizing, press then release).

@Ralith
Copy link
Contributor

Ralith commented Apr 22, 2017

What is the use-case for allowing simultaneous event polling from separate threads?

I've been curious about this as well. There's an awful lot of juggling that has to be done to maintain/expose state in EventsLoop in a Sync manner, and it all ends up artificially serialized by the resultant locking anyway.

@mitchmindtree
Copy link
Contributor Author

@tomaka it's been a while now and I'm still not sure what the value is in allowing poll_events and run_forever to be called simultaneously in separate threads. It seems to me that EventsLoop really should not be Sync at all, and instead should use some Proxy (similar to the old WindowProxy) to allow for interrupts to be signalled from separate threads. It'd be great to get your thoughts on this.

@tomaka
Copy link
Contributor

tomaka commented May 22, 2017

@mitchmindtree Let's make the change then I guess.

@mitchmindtree
Copy link
Contributor Author

This is no longer necessary as of #191 - closing.

tmfink pushed a commit to tmfink/winit that referenced this pull request Jan 5, 2022
…pdates

Pathfinder magicleap demo updates
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants