Adds an idle loop to the x11 backend, and uses it for repainting.

[jneem]

Fixes #932 and #935.

[psychon]

I left some comments. Feel free to ignore whichever parts you want to ignore. I am not quite confused about your thread-safety requirements / use of threads.

[jneem]

Thanks for the comments! Regarding the threading: the intention (although it probably isn't correct right now) is to do the interaction with X11 only the main thread, but to support threads for other things. For example, IdleHandle is Send + Sync, so you can hand it to another thread. That thread can use the handle to queue a callback, but then that callback will be run on the main thread. Hopefully this explains the use of pipes.

Regarding the interaction with x11rb, could you expand on what the thread-safety issues are? I noticed that XCBConnection is Send + Sync, but maybe it shouldn't be? Or maybe a better question is: if I wrap our XCBConnection in a struct that is !Sync, will that avoid all potential threading issues. (Should I make it !Send also?) Actually, on windows our WindowHandle type is already !Send and !Sync, so this should probably be replicated on other platforms to avoid portability issues.

[psychon]

Regarding the interaction with x11rb, could you expand on what the thread-safety issues are?

The issue is that libxcb and XCBConnection have an internal queue of pending events that were read from the socket, but not yet passed to the caller. Thus "an event is (potentially) pending" is not the same as "the socket is readable".

Let's say that the main thread is "almost done" with a main loop iteration and is about to call poll(). We now have a race condition and another thread gets to run some code.
This other thread now does conn.get_input_focus()?.reply(). Thus, it sends a request and waits for its reply. To wait for the reply, it has to read X11 packages from the connection until it "finds" the reply to the request. Any events that it reads ends up in the internal queue.
Now the main thread continues with poll() and blocks even though there are pending events.

Hopefully this makes the issue clearer.

I noticed that XCBConnection is Send + Sync, but maybe it shouldn't be?

Well, you could do what Qt5 is doing: You spawn a thread that does loop { let event = conn.wait_for_event(); send_to_main_loop(event); }. This wait_for_event() is made to work correctly by x11rb (via a condition variable, std::sync::Condvar). Thus, in this scenario, everything works correctly and the connection really is Sync.

The issue is that "poll() on the socket to know when to call poll_for_event()" is not thread-safe, but all the APIs themselves are thread-safe.

Does that make sense? Do you have any ideas how x11rb could work differently?

[jneem]

Thanks, that makes a lot of sense. The only thing I would suggest to change in x11rb would be to have an explanation like the one you gave in the API docs. I've been kind of spoiled by rust over the last couple years, to the extent that if something Send + Sync, I just assume that there are no threading issues...

As far as druid is concerned, it sounds to me like everything will be fine as long as we restrict the xcb connection to one thread. As far as I can tell, access to the connection is restricted to the WindowHandle and the cairo context that we create; I've marked the WindowHandle as !Send and !Sync, and the cairo context is exposed as piet::CairoRenderContext, which is already !Send and !Sync. So I think the threading issue should be ok now.

[luleyleo]

Sorry to let this sit around for so long.
Looks pretty good so already, got a few more questions and suggestions.

[jneem]

Ok, I think the review comments are addressed now.