I have an application that's streaming frames from a webcam. After a few minutes of streaming, the QSocketNotifier associated with camera fd stops generating activated events.

This might be a camera hardware, firmware, or RPI kernel issue, but I want to make sure my use of a QSocketNotifier instead of the exact code in the Vl42 example isn't part of the problem



In examples mainLoop() function there is a blocking select:

Qt Code: 
  1. r = select(fd + 1, &fds, NULL, NULL, &tv);
  2.                 if (-1 == r) {
  3.                 if (EINTR == errno)
  4.                    continue;
To copy to clipboard, switch view to plain text mode 

I have these lines of code instead:

Qt Code: 
  1. fd = open(dev_name.toAscii().data(), O_RDWR /* required */ | O_NONBLOCK, 0); 
  2. notify_fd = new QSocketNotifier(fd, QSocketNotifier::Read);
  3. connect(notify_fd, SIGNAL(activated(int)), this, SLOT(read_frame(int)), Qt::QueuedConnection );
To copy to clipboard, switch view to plain text mode 

So, what happens when the fd associated the QSocketNotifier breaks out of the select with EINTR==errno? I've been assuming that's a QSocketNotifier::Exception event, so creating the QSocketNotifier using a QSocketNotifier::Read type would result in exceptions like the EINTR==errno being ignored. That's the equivalent of the example code.

Is this true? Can I check errno in the read_frame slot, or will it likely be reset before the slot code executes?

Next step will be to redo the code without the QtSocketNotifier, but that will take a few hours to get working, I think.

Thanks!