[FFmpeg-devel] Network IO in FFmpeg (was: abstractable threading api)
Nicolas George
george at nsup.org
Thu Apr 10 16:49:37 CEST 2014
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.
Regards,
--
Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140410/7eeecd38/attachment.asc>
More information about the ffmpeg-devel
mailing list