[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.
>
> Not meaning to be a downer, but you misuse the phrase "reading in
> nonblocking mode". Reading in non-blocking mode means working with
> URLContext opened with AVIO_FLAG_NONBLOCK. And a read of such context
> should result with immediately available data, or AVERROR(EAGAIN).
> Your technique seems hacky. I don't know FTP protocol, but it is
> strange to hear that you cannot know if message from remote party
> completed. Anyway, if i needed to check without blocking if there's
> more data available on tcp connection, i'd get TCP file descriptor
> with conn_control->prot->url_get_file_handle(conn_control), and poll()
> on it.

So far all you described was done internally. TCP could be used as
black box. There was an API to break a loop, end of story,
For me getting descriptor and polling it would break modulatiry and
duplicates code.
Your commit changes that logic and I pointed it to discuss it. I think
that's the idea of community.
And I really don't see a reason to discuss FTP protocol here and all
your doubs about it, because there was a time for it when I submitted
it.

Best Regards,
Lukasz Marek