[FFmpeg-cvslog] In retry_transfer_wrapper, do not check url_interrupt_cb,

[Michael Niedermayer]

On Fri, Mar 04, 2011 at 05:23:51PM +0100, Nicolas George wrote:
> Le quartidi 14 vent?se, an CCXIX, Martin Storsj? a ?crit?:
> > Perhaps a fix which would match the old behaviour more closely wold be to 
> > move the url_interrupt_cb() check down, either into the if (EAGAIN) 
> > branch, or at least to after transfer_func has been called. That way, 
> > url_interrupt_cb() triggering won't make writes to local files fail, which 
> > wouldn't have blocked anyway.
> 
> I believe the attached patch fixes things.
> 
> I am not quite happy with the whole thing, but I believe this can not be
> avoided: we are in the situation of the unstoppable bullet hitting the
> unbreakable armor: url_read_complete and url_write both guarantee to
> read/write all the requested data unless something fatal happened, while
> url_interrupt_cb guarantees to interrupt any transfer. In the end,
> url_interrupt_cb wins, but it necessarily kills the protocol context.

a 2 or 3 level abort should be used. Like unix TERM & KILL
in the depth of the protocols it would be a
if(url_interrupt_cb() >= 2){
}

outside where a safe exit is possible a 
if(url_interrupt_cb() >= 1){
}

and ffmpeg should send a 1 on the first "q" press and then when "q" is
pressed again send a 2 

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20110306/0b866c15/attachment.pgp>