On Tue, 2011-06-28 at 09:43 -0300, Mauro Carvalho Chehab wrote: > Em 28-06-2011 09:21, Andy Walls escreveu: > > It is also the case that a driver's poll method should never sleep. > > True. > > 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. Sure, but that doesn't solve the problem of an app only select()-ing or poll()-ing for exception fd's and not starting any IO. > > 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. It isn't. >From the specification for select(): http://pubs.opengroup.org/onlinepubs/009695399/functions/select.html "A descriptor shall be considered ready for reading when a call to an input function with O_NONBLOCK clear would not block, whether or not the function would transfer data successfully. (The function might return data, an end-of-file indication, or an error other than one indicating that it is blocked, and in each of these cases the descriptor shall be considered ready for reading.)" To a userspace app, a non-blocking read() can always return an error, regarless of the previous select() or poll() result. And all applications that use select() or poll() folowed by a nonblocking read() should be prepared to handle an errno from the read(). However, that excerpt from the select() specification does imply, that perhaps, the driver should probably start streaming using a work item and one of the CMWQ workers, so that the read() doesn't block. Regards, Andy -- 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
