[PATCH] client: Add acquire-fd API to avoid requiring a polling main thread

[Thiago Macieira]

On segunda-feira, 25 de março de 2013 19.49.32, Uli Schlachter wrote:
> So wl_display_acquire_fd() would do:
> 
>     if (old_state == VOLUNTEER_READER) {
>         write(display->reader_pipe[1], &c, 1);
>         pthread_cond_wait(&display->pipe_cond, &display->mutex);
>         read(display->reader_pipe[0], &c, 1);
>     }

There might be a priority inversion / resource starvation problem here.

When the other thread returns to its caller, that caller may call the dispatch 
function again and cause it to poll(2) again, before the pipe is emptied. 
Since the pipe is still readable, poll(2) will return immediately and it 
returns to the caller. Nothing changed since the last time, so the caller may 
again cause it to dispatch.

That other thread will be always in runnable state and will be at 100% CPU 
usage (busy-loop), waiting for this (suspended) thread to empty the pipe. The 
OS may take some time to wake it up from cond_wait. Meanwhile, we're burning 
CPU and consuming battery.

Unless there's something before the call to poll(2) that will prevent it from 
happening in the first place. I have to confess I have not yet understood this 
problem to confirm or deny that.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130325/3e3e8364/attachment.pgp>