EventsLoopProxy does not wakeup the EventsLoop unless it's already blocked

[pedrocr]

See the conrod issue for a discussion on this:

PistonDevelopers/conrod#1051

To get a non-polling multi-threaded app running the conrod examples do the following:

1. Create a rendering thread that reads inputs and writes it's output to a set of std::sync::mpsc channels
2. Block the main loop on EventsLoop::run_forever()
3. In the rendering thread whenever we have written the output use an EventsLoopProxy::wakeup() to wake up the main thread
4. Inside run_forever() pass on events to the channel until we get an Awakened
5. Finish the main loop by rendering from the second channel and go back to blocking in run_forever()

The problem with this setup is that step 3 doesn't reliably unblock run_forever() because if you use EventsLoopProxy::wakeup() when not inside run_forever() the next time run_forever() runs it will not immediately unblock.

Is this intended behavior? @mitchmindtree was expecting the semantics of wakeup() to be that if it's called it will unblock run_forever() immediately when it gets called and that does sound much more useful.

[Osspial]

From skimming the conrod issue, this seems to be an issue with X11. @vberger - does the EL2.0 PR fix this?

[elinorbgr]

It should yes. Whenever the event loop blocks, it blocks until an x11 event or an user event arrives, whichever comes first.