[FFmpeg-devel] [PATCH 3/5] ff_network_wait_fd_timeout(): check for interrupt before operation

[Lukasz M]

>> >>> Yes, this way data won't be transmitted even if socket is readable
>> >>> (writable). So what? Abortion is requested from upper layers, this
>> >>> fact has top priority.
>> >>
>> >> Maybe we have different use cases in mind, but what is the reason to
>> >> call read/write operation when this operation will never happen,
>> >> because it will be interrupted before try?
>> >
>> > The patched procedure is not used straightly by user, but by
>> > libavformat internal routines, including (indirectly) muxers, demuxers
>> > etc. These internal routines of libavformat may not be checking
>> > interrupt callback.
>> > So in conflict of interests - user wants to terminate blocking
>> > operation, and e.g. demuxer wants to get data - user is top priority.
>>
>> Ok, I see you point i think. The issue is there is no way to use
>> protocol in non blocking mode. The operation is aborted before try.
>
>
>> Anyway, in case maintainers decide to merge it, function's doxy should
>> be updated too.
>
> iam happy to leave the review and approval or rejection of the patch
> to you if you want. You are already working on it and it seems none
> of the other people who actively worked on the network code recenty
> (nicolas, reimar, martin, ... ) replied so ...

I don't mind merging it, but there is a "collision" of two
functionalities/use cases that are tried to be solved by one callback
and it seems to be impossible.
These cases are:
- interrupt I/O operation entirely because it is not needed anymore.
- interrupt I/O operation when descriptor is not ready
My proposition is to megre Andrey's commits and I will extend
AVIOInterrupt struct by one more callback to support second use case.
It regards network operation so checking and optionally calling one
more callback is not relevant to performance and provides flexibility
in using protocols.

Best Regards,
Lukasz Marek