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.

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).

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.

@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.

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

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