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

Michael Niedermayer michaelni at gmx.at
Fri Jul 12 02:40:59 CEST 2013

On Thu, Jul 11, 2013 at 01:33:42AM +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 ...


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
-------------- 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/5c45aa42/attachment.asc>

More information about the ffmpeg-devel mailing list