[pulseaudio-discuss] [PATCH] mainloop: Map POLLNVAL to PA_IO_EVENT_ERROR.

[Tanu Kaskinen]

On Fri, 2011-12-30 at 09:06 +0530, Arun Raghavan wrote:
> On Wed, 2011-12-28 at 14:29 +0200, Tanu Kaskinen wrote:
> > I don't see any reason why POLLNVAL should be ignored like
> > it is now without this patch. PA_IO_EVENT_ERROR seems to be
> > the best choice for reporting the IO event type, because
> > POLLNVAL is an error condition and adding a new IO event
> > type just for POLLNVAL probably wouldn't add any value.
> 
> It gives more information about what went wrong, and I don't see the
> gain of throwing away this information (after looking at the code,
> adding a PA_IO_EVENT_INVALID to the places where PA_IO_EVENT_ERROR is
> handled should be relatively easy).

The reason why I thought adding PA_IO_EVENT_INVALID would not be useful
was that it wouldn't solve my immediate problem any better than reusing
ERROR, and actually it would not solve the problem at all without
further debugging: I would need to find out what IO event exactly is
causing the 100% cpu use and then add a check for INVALID to that code.
I still don't know what code that is - I suspected GStreamer, but it
seems that pulsesink doesn't create any IO events of its own. There were
two fds involved. The other one should be the unix socket that is used
to communicate with the daemon. I think that code can't enter a busy
loop even if POLLNVAL occurs. I don't know what the other fd is - I'll
need to investigate this more.

Regarding the point that adding a check for INVALID should be easy: it's
easy for Pulseaudio code, but it's not easy to update every client
application that adds its own IO events to the Pulseaudio mainloop. I
don't know if there are any applications that actually do that, though.

For some reference on how others do this, I had a look at GLib's API.
GLib seems to have a separate flag for POLLNVAL: G_IO_NVAL. On the other
hand, the documentation for GPollFD says this: "Typically for reading
from a file descriptor you would use G_IO_IN | G_IO_HUP | G_IO_ERR, and
for writing you would use G_IO_OUT | G_IO_ERR." Why G_IO_NVAL is not
included there?

Anyway, either way is ok for me, and I'd prefer slightly more a separate
flag for INVALID after all.

-- 
Tanu