On 06/03/2016 03:53 PM, Nicolas George wrote:
Le nonidi 9 prairial, an CCXXIV, Jan Sebechlebsky a écrit :
If I understand it correctly, I think this will be handled quite smoothy -
you don't have to kill the blocked write, the application has to call
write_trailer anyway before closing the muxer, so I guess this is the place
where tee will wait for the muxer's pending write operation to finish. So
application will know, that after call to write_trailer all operations are
finished.
There is no "after call to write_trailer": the real muxer is blocked
writing, it will not terminate. By pushing it in a thread, you may have
achieved non-blocking writes for the application, but that just pushed the
issue a bit further.
To achieve real non-blocking operation, you need to have all the muxers and
protocols stack working in non-blocking mode, or you need asynchronous
killing of I/O operations. Asynchronous killing of I/O operations exists,
that is pthread_cancel(), but it is quite tricky to use and we had no end of
portability issues with it too.
I guess then, that implementing it without killing blocked threads
should not introduce any new problems - the process will hang as it does
now in this kind of situation.
I can try to take a look if canceling the thread could be used. How
do you imagine this (like that there will be a timeout enforced by
killing the thread?). Do you know where are I/O operations which can
block forever without timeouting used, so I can try to take a look at
some particular case?
Regards,
Jan
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
