Anton Khirnov (12022-11-09): > > 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.
I do not know how your sentence connects to mine. > 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. This is why I have wanted to fix the design of demuxers and demuxer-like components for years, but it is a tremendous work. In the meantime, we just do with "av_usleep(1000)" and it is terrible. > 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). Sleeping is the only correct reaction to EAGAIN. -- Nicolas George _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
