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

[Lukasz M]

>> 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
>
> First i thought that you are addressing the use case "read, interrupt,
> seek, read". (As far as i know and remember, there's no guarantee this
> use case would work, but somebody uses it happily.)
> But re-reading you i see you mean something else. Could you please
> describe one or more cases where such feature would be needed? It
> would be great if you provide some code and/or setup instructions, so
> we could check the problem and the effect of these changes.

I'm sorry if I wasn't clear.
You can reffer libavformat/ftp.c file where FTP protocol is implemented.
The case I have in mind is when you use TCP protocol to implement
different protocol.
In this example FTP protocol uses two TCP connections (this is a nature of FTP).
It is good to use ffmpeg's implementation to be sure it is portable.
One of these connections is a "control connection" where you
communicate with the server on Request - Response basics.
Requests and Responses are line of text (human readable).
Responses from the server may be asynchonous, and may be multilined.
when you get response you may want to read socket again to be sure
there is no data left you want to precess as a result of previous
Request. (for example response was larger then your read buffer). When
you don't do that there is a chance this unread line will affect next
Request's Response. When you read in blocking mode then everything
freeze where there was nothing else.

Patch you created doesn't allow to read data in nonblocking mode, so
you cannot do that procedure I described.
Fortunatelly FTP protocol is the only place where this case occurs,
and should work anyway.
There are explicit codes checkes and assupotion each line have to be
ended with new line character, so a chance something wrong happen is
very low, but in the future someone may occur this issue when this may
be real issue. Thats why I pointed that your change has possibly big
side effects and it's worth to leave a way to handle it somehow.

Best Reagrds,
Lukasz Marek