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

[wm4]

On Thu, 10 Apr 2014 16:49:37 +0200
Nicolas George <george at nsup.org> wrote:

> Le nonidi 19 germinal, an CCXXII, LANGLOIS Olivier PIS -EXT a écrit :
> > > This thread has caught my attention and I went to see how
> > > pthread_cancel() was used in libavformat/udp.c and I might have spotted a
> > > race condition in it.
> > >
> > > cancellation points are implemented inside glibc not in the kernel. That
> > > means that once the cancellation point check is done and the thread is
> > > blocked inside the kernel, cancelling the thread will have no effect.
> > >
> > > In order to have the code behave as designed,
> > >
> > > pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, NULL);
> > >
> > > should be used. asynchronous cancels are implemented with RT signals.
> > > For that reason only async cancels can interrupt and cancel a thread that is
> > > already inside a system call.
> > 
> > My mistake. Ignore this whole post. Half of it is true. The other half is
> > that inside cancellation point functions, async cancel type if flipped
> > on/off around the syscall. ie:
> > 
> >       int oldstate = LIBC_CANCEL_ASYNC ();
> > 
> >       r = INTERNAL_SYSCALL (clock_nanosleep, err, 4, clock_id, flags, req,
> >                             rem);
> > 
> >       LIBC_CANCEL_RESET (oldstate);
> 
> Thanks for clarifying. The idea of "cancellation points" would have been
> pretty useless if it did not reach the actual blocking system calls, but
> that would not have been the first time an unusable API found its way into
> Unix.

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