[PATCH 0/8] Thread safety patches and 1.0 plan
krh at bitplanet.net
Tue Oct 9 19:37:57 PDT 2012
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
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.
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(-)
More information about the wayland-devel