Re: [FFmpeg-devel] [PATCH] avformat/unix: properly handling timeout at reading

2018-03-21 Thread Nicolas George
Bodecs Bela (2018-03-21): > Should not the unix_write behaves the  same? so, when > > ret = send(s->fd, buf, size, MSG_NOSIGNAL); > > return 0 in case of SOCK_STREAM type, then the unix_write() should return > AVERROR_EOF instead of 0? No: there is no EOF reporting on writing, since the

Re: [FFmpeg-devel] [PATCH] avformat/unix: properly handling timeout at reading

2018-03-21 Thread Bodecs Bela
2018.03.20. 22:41 keltezéssel, Nicolas George írta: Bodecs Bela (2018-03-20): start a. and in a separate terminal window start b.  After 10 seconds a. terminates but b. remains running on infinite time. Ok, got it. But I expected b. to

Re: [FFmpeg-devel] [PATCH] avformat/unix: properly handling timeout at reading

2018-03-20 Thread Bodecs Bela
2018.03.20. 22:41 keltezéssel, Nicolas George írta: Bodecs Bela (2018-03-20): start a. and in a separate terminal window start b.  After 10 seconds a. terminates but b. remains running on infinite time. Ok, got it. But I expected b. to

Re: [FFmpeg-devel] [PATCH] avformat/unix: properly handling timeout at reading

2018-03-20 Thread Nicolas George
Bodecs Bela (2018-03-20): > start a. and in a separate terminal window start b.  After 10 seconds a. > terminates but b. remains running on infinite time. Ok, got it. > But I expected b. to > terminate after 1 sec (100 microsec) when no

Re: [FFmpeg-devel] [PATCH] avformat/unix: properly handling timeout at reading

2018-03-20 Thread Bodecs Bela
2018.03.20. 21:23 keltezéssel, Nicolas George írta: Bodecs Bela (2018-03-20): I am sorry, but you misunderstood me. When recv() return 0 it means that no data was read. And for the third time I am asking how you observe that. What is your testing procedure? Regards, ah, sorry. Let's see

Re: [FFmpeg-devel] [PATCH] avformat/unix: properly handling timeout at reading

2018-03-20 Thread Nicolas George
Bodecs Bela (2018-03-20): > I am sorry, but you misunderstood me. When recv() return 0 it means that no > data was read. And for the third time I am asking how you observe that. What is your testing procedure? Regards, -- Nicolas George signature.asc Description: Digital signature

Re: [FFmpeg-devel] [PATCH] avformat/unix: properly handling timeout at reading

2018-03-20 Thread Bodecs Bela
2018.03.20. 20:58 keltezéssel, Nicolas George írta: Bodecs Bela (2018-03-20): see the retry_transfer_wrapper() in avio.c If ret = transfer_func(h, buf + len, size - len); is always zero, so it gets into infinite loop. transfer_func is unix_read in case of unix protocol. Let me be more

Re: [FFmpeg-devel] [PATCH] avformat/unix: properly handling timeout at reading

2018-03-20 Thread Bodecs Bela
2018.03.20. 20:56 keltezéssel, Bodecs Bela írta: 2018.03.20. 20:50 keltezéssel, Nicolas George írta: Bodecs Bela (2018-03-20): avio rw_timeout handling in retry_transfer_wrapper() is based on returning EAGAIN from protocols' read function. unix_read function returns 0 in case of no data

Re: [FFmpeg-devel] [PATCH] avformat/unix: properly handling timeout at reading

2018-03-20 Thread Nicolas George
Bodecs Bela (2018-03-20): > see the retry_transfer_wrapper() in avio.c If > > ret = transfer_func(h, buf + len, size - len); > > is always zero, so it gets into infinite loop. > > transfer_func is unix_read in case of unix protocol. Let me be more accurate: I am pretty sure you analysis is

Re: [FFmpeg-devel] [PATCH] avformat/unix: properly handling timeout at reading

2018-03-20 Thread Bodecs Bela
2018.03.20. 20:50 keltezéssel, Nicolas George írta: Bodecs Bela (2018-03-20): avio rw_timeout handling in retry_transfer_wrapper() is based on returning EAGAIN from protocols' read function. unix_read function returns 0 in case of no data was read. It happens even if timeout it set for a

Re: [FFmpeg-devel] [PATCH] avformat/unix: properly handling timeout at reading

2018-03-20 Thread Nicolas George
Bodecs Bela (2018-03-20): > avio rw_timeout handling in retry_transfer_wrapper() is based on returning > EAGAIN from protocols' read function. unix_read function returns 0 in > case of no data was read. It happens even if timeout it set for a valid > value and thus rw_timeout handling can not work

[FFmpeg-devel] [PATCH] avformat/unix: properly handling timeout at reading

2018-03-20 Thread Bodecs Bela
Dear All, avio rw_timeout handling in retry_transfer_wrapper() is based on returning EAGAIN from protocols' read function. unix_read function returns 0 in case of no data was read. It happens even if timeout it set for a valid value and thus rw_timeout handling can not work and wait for ever.