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

[Michael Niedermayer]

On Fri, Jul 12, 2013 at 02:09:45PM +0200, Lukasz M wrote:
> >> >>> 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.
"

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130712/ebad68c9/attachment.asc>