Em 28-06-2011 09:21, Andy Walls escreveu: > Mauro Carvalho Chehab <mche...@redhat.com> 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 majord...@vger.kernel.org >> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
