[Wayland-bugs] [Bug 60942] Threaded wayland EGL clients stall

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=60942

Rob Bradford <rob at robster.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #2 from Rob Bradford <rob at robster.org.uk> ---
I think this should be resolved with the changes that have been made following
this commit (and the appropriate changes in Mesa):


commit 3c7e8bfbb4745315b7bcbf69fa746c3d6718c305
Author: Kristian Høgsberg <krh at bitplanet.net>
Date:   Sun Mar 17 14:21:48 2013 -0400

    client: Add wl_display_prepare_read() API to relax thread model assumptions

    The current thread model assumes that the application or toolkit will have
    one thread that either polls the display fd and dispatches events or just
    dispatches in a loop.  Only this main thread will read from the fd while
    all other threads will block on a pthread condition and expect the main
    thread to deliver events to them.

    This turns out to be too restrictive.  We can't assume that there
    always will be a thread like that.  Qt QML threaded rendering will
    block the main thread on a condition that's signaled by a rendering
    thread after it finishes rendering.  This leads to a deadlock when the
    rendering threads blocks in eglSwapBuffers(), and the main thread is
    waiting on the condition.  Another problematic use case is with games
    that has a rendering thread for a splash screen while the main thread
    is busy loading game data or compiling shaders.  The main thread isn't
    responsive and ends up blocking eglSwapBuffers() in the rendering thread.

    We also can't assume that there will be only one thread polling on the
    file descriptor.  A valid use case is a thread receiving data from a
    custom wayland interface as well as a device fd or network socket.
    The thread may want to wait on either events from the wayland
    interface or data from the fd, in which case it needs to poll on both
    the wayland display fd and the device/network fd.

    The solution seems pretty straightforward: just let all threads read
    from the fd.  However, the main-thread restriction was introduced to
    avoid a race.  Simplified, main loops will do something like this:

        wl_display_dispatch_pending(display);

        /* Race here if other thread reads from fd and places events
         * in main eent queue.  We go to sleep in poll while sitting on
         * events that may stall the application if not dispatched. */

        poll(fds, nfds, -1);

        /* Race here if other thread reads and doesn't queue any
         * events for main queue. wl_display_dispatch() below will block
         * trying to read from the fd, while other fds in the mainloop
         * are ignored. */

        wl_display_dispatch(display);

    The restriction that only the main thread can read from the fd avoids
    these races, but has the problems described above.

    This patch introduces new API to solve both problems.  We add

        int wl_display_prepare_read(struct wl_display *display);

    and

        int wl_display_read_events(struct wl_display *display);

    wl_display_prepare_read() registers the calling thread as a potential
    reader of events.  Once data is available on the fd, all reader
    threads must call wl_display_read_events(), at which point one of the
    threads will read from the fd and distribute the events to event
    queues.  When that is done, all threads return from
    wl_display_read_events().

    From the point of view of a single thread, this ensures that between
    calling wl_display_prepare_read() and wl_display_read_events(), no
    other thread will read from the fd and queue events in its event
    queue.  This avoids the race conditions described above, and we avoid
    relying on any one thread to be available to read events.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-bugs/attachments/20130708/1f50c93d/attachment.html>