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

[Nicolas George]

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.

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

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

> So I guess my order of preference would be "closing the socket" (or
> using current pthread cancel code, which happens to do this) then
> "poll+self-pipe"

Having an order of preference is way too premature before discussing the
direction we want to take this receiving thread (see the mail I am currently
writing) and having someone who actually knows the windows API explain the
possibilities. Note that there is absolutely no obligation to have the same
implementation for both OSes.

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.

Now it just needs someone to implement that.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20131222/703f12a7/attachment.asc>