[PATCH 0/8] Thread safety patches and 1.0 plan

Hi all, Wayland 1.0 is just around the corner and we have a couple of blockers for that release: thread safety of the client side API and the surface commit feature. Pekka has been working on the commit part and these eight patches rework the client library to be thread safe. I've been meaning to release 1.0 this week, but we may have to take a few more days to let these changes settle down. We ended up changing the API and protocol a little more and a little closer to 1.0 than I was hoping we'd need to. Other than that I'm pretty happy with how these changes worked out. The patches remove more lines than they add, mainly because some of the patches removes hand-written code in favor of generating more code from the protocol XML. One problem with the API was that wl_display_iterate() would invoke any event callback as they come in, and could for example call into EGL code that expects an EGL mutex to be held or call an input event handler from within the EGL mutex in a different thread. So the big change is the introduction of struct wl_event_queue, that lets a subsystem (such as EGL, for example) isolate events from its objects on a dedicated queue. This way only that subsystem (in the right thread under the right lock etc) can execute those callbacks and it won't execute any unrelated callbacks. Another problem was the global listener API. We can't support a callback interface like that in a thread-safe way, but we already have a solution for thread safe callbacks: the event queue. So the fix here is to split the global registry (the bind request and the global and global_removed events) into their own interface. This way multiple subsystems can get their own wl_registry object and the server will handle sending out events to each listener in a thread safe way. Finally, the fd API used an update callback when the wayland client library needed to change the poll flags on its socket fd. This also breaks down in the face of multiple threads, since any thread can send a request at any time and thus trigger the update callback. What we do instead is to just ask that the client flushes the wl_display protocol buffer before blocking in its mainloop. If the flush receives EAGAIN, the client should change its mainloop to poll for writable on the fd. This turns out to be a simpler and more efficient API, since typically we'll be able to completely flush the buffer every time, and won't have to change the poll flags at all. With these and Pekkas changes, we'll have to update the clients once more. Unfortunately Mesa 9.0 was just released, so we'll have to get these changes into a 9.0.1 release. Toolkits will need a change as well. Anyway, I would much appreciate feedback on these patches, but I do also expect that we'll merge them (and Pekkas patches) within a couple of days, update clients and toolkits and then cut the 1.0 release of wayland next week. Kristian protocol/wayland.xml | 41 ++--- src/connection.c | 190 ++++++++++++------------ src/event-loop.c | 4 + src/scanner.c | 60 +++++--- src/wayland-client.c | 371 +++++++++++++++++++++------------------------- src/wayland-client.h | 51 ++----- src/wayland-private.h | 19 ++- src/wayland-server.c | 149 ++++++++++++------- src/wayland-server.h | 5 +- tests/connection-test.c | 82 +++------- tests/os-wrappers-test.c | 31 +--- 11 files changed, 480 insertions(+), 523 deletions(-)