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

[Roger Pack]

On 5/8/14, Hendrik Leppkes <h.leppkes at gmail.com> wrote:
> 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)

It would be nice to understand how/where it is leaking.

> - 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.

Right I think.