[Bug 794977] gstpoll: should not handle POLLPRI as read

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=794977

Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nicolas at ndufresne.ca

--- Comment #6 from Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> ---
(In reply to Tim-Philipp Müller from comment #4)
> I've got nothing against this in principle, but I'm concerned that it might
> break backwards compatibility.

Unless we want to supports bugs in Linux < 2.4, no. POLLPRI never applies to
read(). So polling it will simply wakeup the CPU for no reason if you have a
non-blocking FD, and cause blocking IO if you have a blocking FD.

> 
> Someone doing a read and getting stuck - why can't they just set the socket
> to non-blocking if they use GstPoll anyway? That sounds like a potential
> problem in itself?

I think Guillaume meant doing a systemcall, blocking / non-blocking cannot be
controlled on all the syscalls. For V4L2 it is possible to control that, but we
don't because we support V4L2 driver without polling capabilities. I'm fine
dropping this support of course. Yet, I think fixing GstPoll to properly
differentiate these two, which have a totally orthogonal meaning. We want from
GstPoll to tell us the truth, so we don't randomly call into the OS to "try"
and see what the poll() call already said.

A small note about windows, the polling event for "accept" is different on that
platform. I think it's fine to manage this as read, because that how it is
expected to be on posix, and listener don't have any other data anyway.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.