-
Notifications
You must be signed in to change notification settings - Fork 948
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
panic!
on overlapping calls to poll_events
and run_forever
#136
Conversation
Unfortunately that's not acceptable. |
I guess it could be OK to leave this to the backends to decide, as long as it was well documented in the On the other hand, a user using 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). |
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 |
@tomaka it's been a while now and I'm still not sure what the value is in allowing |
@mitchmindtree Let's make the change then I guess. |
This is no longer necessary as of #191 - closing. |
…pdates Pathfinder magicleap demo updates
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
andrun_forever
across threads - is this OK? Or is this something that should be supported?