[FFmpeg-devel] Network IO in FFmpeg (was: abstractable threading api)
rogerdpack2 at gmail.com
Mon Dec 23 20:46:09 CET 2013
On 12/22/13, Nicolas George <george at nsup.org> wrote:
> Le decadi 30 frimaire, an CCXXII, Roger Pack a écrit :
>> Do you have an example where this doesn't work?
> It takes five minutes to write one.
The code I did write and test worked--the ruby code. I doubt I would
be able to create a failing test case in C land for the OS's I have
available to me, feel free to prove me wrong :)
>> (ruby) code:
>> on OS X, windows, and Linux and (at least with ruby 1.8.x) closing the
>> socket seemed to work ok. However, this may have been because at
>> first glance it seems to do a select before doing the actual recv...
> Possible. A few more tests show that shutdown(s, SHUT_RDWR) interrupts the
> read on Linux. But that is not specified anywhere. Systems where sockets
> implemented in userland on top of other APIs, like Solaris, are likely to
> behave differently.
Solaris has pthreads so could use that option? I suppose one option
is to use the "cancel to interrupt" option only for windows.
>> Anyway the good news here is that it works today on windows as is,
>> because AFAICT it's using the "closing the socket to interrupt the
>> thread" trick, FWIW.
> I do not think this is a good news.
I think the reason it "accidentally" happens to work in windows today
is because the socket is closed before sending the pthread cancel
message. Which may or may not be a bug depending on how you see it.
I think what it was *meant* to do was to send pthread cancel *then*
close it, but maybe in windows it can be made to still close it early.
>> (I assume poll() is the equivalent of using select in windows?)
>> The disadvantage to this and the reason it is frowned upon is because
>> it requires a timeout worth of time to cancel the thread?
> There is that, and there is the other side of the coin: it causes frequent
> useless wake-ups. For small embedded devices, it can ruin the power
Thanks for the clarification.
> Regarding the windows API, I asked around, and here is what I got
> (translated from French by me):
> # The cleanest way is to use asynchronous IO (overlapped IO in Microsoft
> # slang). There are several variants, but in this case I would advise
> # to create an event object signaled when the read is finished and another
> # to request the interruption and to do a WaitForMultipleObjects, or to use
> # a completion port object (which is, in my opinion, the most elegant
> # version of asynchronous IO for windows).
> # For a quick-and-dirty gizmo, CancelSynchronousIo may do the trick.
> # [...] It seems to me there is a race condition that does not exist with
> # the clean solution. Furthermore, the API is less flexible and I suspect
> # will give code that is harder to maintain.
Plus CancelSynchronousIo is only available on vista+ FWIW.
One thought I had was to use the poll+selfpipe option for windows,
pthread cancel for linux, and single threaded for everything else, but
I'll also respond to your other email.
More information about the ffmpeg-devel