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
