[FFmpeg-devel] Network IO in FFmpeg (was: abstractable threading api)

Hendrik Leppkes h.leppkes at gmail.com
Thu May 8 15:43:21 CEST 2014


On Wed, Apr 16, 2014 at 5:07 PM, Nicolas George <george at nsup.org> wrote:
> Le primidi 21 germinal, an CCXXII, wm4 a écrit :
>> I think it's a quality of implementation issue. It is meant to cancel
>> system calls which are specified as cancellation points. Asynchronous
>> cancellation is actually not needed. Though it's possible that glibc
>> and OSX have various bugs (see http://ewontfix.com/2/ ).
>
> I do not understand what you are saying. What I was saying is this:
>
> If cancellation points worked in the libc but not in the kernel, they would
> be completely useless. But that is not the case (in implementations we know
> of), and therefore the issue is moot.
>
> Since it is about cancellation points, it is about DEFERRED cancel, not
> ASYNCHRONOUS cancel. ASYNCHRONOUS cancel is another story entirely, but as
> you write, it is unneeded here.
>

Did we ever get any kind of progress done on this?
I've been using pthreads on windows to make use of the UDP buffer, but
I found a problem with the interaction of the pthreads-w32 library and
interaction with windows threads (it causes a leak of thread handles)
- plus after checking the pthreads-w32 code, I'm unsure
pthreads_cancel actually works properly, and the UDP code may just
happen to close down "by accident" somehow.

I originally switched back to pthreads because of a user complaining
about UDP problems, and it fixed it nicely, but now facing this
again...
I'm willing to work on any solution, as long as we can decide on one to pursue.

- Hendrik


More information about the ffmpeg-devel mailing list