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

[Roger Pack]

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:
>> https://gist.github.com/rdp/8058776
>> 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
> are
> 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
> savings.

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
> either
> # 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
> it
> # 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.
Thanks!
-roger-