Em 28-06-2011 09:21, Andy Walls escreveu: > Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> wrote: >> I'm not very comfortable with vb2 returning unexpected errors there. >> Also, >> for me it is clear that, if read will fail, POLLERR should be rised. >> >> Mauro. >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-media" >> in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > It is also the case that a driver's poll method should never sleep. True. > I will try to find the conversation I had with laurent on interpreting the POSIX spec on error returns from select() and poll(). I will also try to find links to previos discussion with Hans on this. > > One issue is how to start streaming with apps that: > - Open /dev/video/ in a nonblocking mode, and > - Use the read() method > > while doing it in a way that is POSIX compliant and doesn't break existing apps. Well, a first call for poll() may rise a thread that will prepare the buffers, and return with 0 while there's no data available. > The other constraint is to ensure when only poll()-ing for exception conditions, not having significant IO side effects. > > I'm pretty sure sleeping in a driver's poll() method, or having significant side effects, is not ine the spirit of the POSIX select() and poll(), even if the letter of POSIX says nothing about it. > > The method I suggested to Hans is completely POSIX compliant for apps using read() and select() and was checked against MythTV as having no bad side effects. (And by thought experiment doesn't break any sensible app using nonblocking IO with select() and read().) > > I did not do analysis for apps that use mmap(), which I guess is the current concern. The concern is that it is pointing that there are available data, even when there is an error. This looks like a POSIX violation for me. Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
