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

[Andrey Utkin]

2013/7/12 Lukasz M <lukasz.m.luki at gmail.com>:
>>> 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.

--
Andrey Utkin