[PATCH] client: use the thread reader_count to fix deadlock.

[Daniel Stone]

Hi Boram,

On 8 April 2016 at 00:58, Boram Park <boram1288.park at samsung.com> wrote:
> This patch solves the deadlock issue of the below scenario.
>
>   1. A thread polls several fds including the wayland's fd.
>   2. This thread probably calls wl_display_prepare_read() before polling
>      fds.
>   3. This thread could be awake by other event source which isn't related
>      with wayland fd.
>   4. After wake up, this thread could call wl_display_dispatch or
>      wl_display_roundtrip for sync operation.

This patch is not correct, and this is the reason why. If the Wayland
FD has no activity, then read_events should not be called (as it will
block), and cancel_read should be called instead.

>   5. Then, when this thread got a done event. this thread will stuck in
>      deadlock because this thread increases +2 reader_count in the same
>      thread.

The API definition of prepare_read is that it must be balanced with
read_events or cancel_read. If you call either read_events or
prepare_read - depending on whether or not the FD has activity -
before you attempt to dispatch/roundtrip, the reader_count will be
correct. This is as per the documentation in
wl_display_prepare_read_queue.

I would prefer not to support this usecase, for much the same reason
that nested mutexes are a very bad idea.

Cheers,
Daniel