[FFmpeg-cvslog] r26318 - trunk/libavformat/aviobuf.c

[Martin Storsjö]

On Wed, 12 Jan 2011, Nicolas George wrote:

> Le tridi 23 niv?se, an CCXIX, Martin Storsj? a ?crit?:
> > This seems to have broken rtpdec_asf, where the chained asf demuxer is 
> > supposed to break and return cleanly on AVERROR(EAGAIN), which now is 
> > swallowed in the ByteIOContext layer.
> > 
> > Is there any better error code that could be used in rtpdec_asf/asfdec for 
> > indicating that there is no more data to return at the moment, but the 
> > stream isn't finished yet.
> 
> That is _exactly_ what EAGAIN means.
> 
> IMHO, looping on EAGAIN is just WRONG. EAGAIN happens when something has
> been set in non-blocking mode: if we do not want EAGAIN, we just do not set
> non-blocking mode. And on the other hand, if someone set non-blocking mode,
> that's because he wants to see EAGAIN to be able to do something else in the
> meantime.
> 
> Looping on EAGAIN is just burning CPU doing busy-wait for absolutely no good
> reason.

In this case, it does fall back to usleeping a bit between retries after a 
few fast retries, but I do see your point.

The issue is that most users of ByteIOContext consider it a nonblocking 
input, and therefore benefit from handling all of that internally, which 
is why this patch was made in the first case.

Another way ahead would be, as user of ByteIOContext, indicate whether it 
wants to use it in nonblocking mode or not.

The use case I had in mind initially would have made some url protocols 
return EAGAIN even while in normal blocking mode, but I managed to solve 
that case in a better way, so I'm ok with reverting this if people feel 
that's the best solution.

// Martin