Re: [FFmpeg-devel] [PATCH 3/5] lavf: replace FFERROR_REDO with AVERROR(EAGAIN)

[Anton Khirnov <anton@khirnov.net>]

Quoting Nicolas George (2022-11-09 09:21:34)
> Anton Khirnov (12022-11-08):
> > Sure, and that's about it. And as I said before - there is no way to
> > tell when a device will be ready, so this is of very limited usefulness.
> 
> This is not true for many devices. Sorry to contradict you once again,
> but you would know it if you had any experience working with devices.

We could really do with fewer of these personal attacks.

> > That is not a meaningful difference. A meaningful difference would be
> > one that has actionable consequences.
> 
> Well, it has actionable consequences: if you treat EAGAIN like REDO you
> introduce a busy wait,

In most devices it's a sleep rather than a busy wait. And in those where
it isn't, it should be.

Furthermore, since the caller has no way of knowing how long to wait,
there is little they can do other than sleeping for a random period and
hoping for the best.

> and if you treat REDO like EAGAIN you introduce a
> significant slowness. Now that you make me mention it, I remember it was
> precisely the reason I introduced REDO: to fix a slowness in resyncs.

I highly doubt that returning control back to the caller will cause any
slowdown in and of itself, it's more about what the caller will do in
response. If they choose to sleep for a random amount of time, then
maybe they should stop doing that (which is exactly what this patchset
does).

-- 
Anton Khirnov
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".