On 04/08/17 09:46, Jorge Ramirez wrote:
> On 08/03/2017 01:53 AM, Mark Thompson wrote:
>>> + }
>>> +
>>> + ret = poll(&pfd, 1, timeout);
>> Can this poll be interrupted?
> yes. when that happens, we indicate no buffer available.
> I think the main program should set the necessary masks.
I was thinking this might violate the send/receive semantics without EINTR
handling - consider a situation where send returns EAGAIN (e.g. by trying to
send 9001 packets to a decoder all at once) so the caller does a receive but
that then races with a signal such that poll returns EINTR, then receive would
return EAGAIN as well which isn't allowed.
If you want to impose signal handling requirements on the caller then that
would need to be documented somewhere.
>>> + if (ret <= 0)
>>> + return NULL;
>>> +
>>> + memset(&buf, 0, sizeof(buf));
>>> + buf.memory = bp->memory;
>>> + buf.type = bp->type;
>>> + if (V4L2_TYPE_IS_MULTIPLANAR(bp->type)) {
>>> + memset(planes, 0, sizeof(planes));
>>> + buf.length = VIDEO_MAX_PLANES;
>>> + buf.m.planes = planes;
>>> + }
>>> + ret = ioctl(bp->fd, VIDIOC_DQBUF, &buf);
>>> + if (ret) {
>>> + if (errno != EAGAIN && errno != EINVAL) {
>> EINVAL is considered ok?
>
> no any ioctl that returns non zero is a fault condition.
> EINVAL (just as EAGAIN) is just not an unrecoverable error (we will just
> return null indicating that there is no buffer available)
EINVAL usually indicates that the arguments were invalid somehow, but I think
with this setup it's just going to call it again with pretty much arguments.
In what case can EINVAL be recoverable?
- Mark
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
