[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.
>
> Adding fields to the callback struct isnt really possible
> " * No members can be added to this struct without a major bump, if
>   * new elements have been added after this struct in AVFormatContext
>   * or AVIOContext.
> "

Right, sorry.
Other way would be to distinguish value returned from callback. For
example 3 flags for
- don't interrupt
- unconditional interrupt
- interrupt waiting

It seems there is not many places to change.

Best Regards,
Lukasz Marek