On Tue, 26 Jun 2012, Måns Rullgård wrote:
Martin Storsjö <[email protected]> writes:
On Tue, 26 Jun 2012, Måns Rullgård wrote:
Martin Storsjö <[email protected]> writes:
This gives the advantage of using this function (instead of the
emulation via select) on systems where it is available, while
retaining compatibility with systems that do not have it.
This requires making our fallback pollfd struct and constants
match what windows would use, so that a build that doesn't have
the windows pollfd definition available at build time would work
if the WSAPoll function is loaded at runtime.
---
libavformat/network.c | 13 +++++++++++++
libavformat/network.h | 3 +++
libavformat/os_support.c | 3 +++
libavformat/os_support.h | 24 ++++++++++++++----------
4 files changed, 33 insertions(+), 10 deletions(-)
Is this really worth the complexity? I doubt we use poll() in a
performance-sensitive way anywhere.
I'm not sure. We do however call poll() once before each read() for
TCP for instance.
Yes, but only on one file descriptor. select() can still perform badly
if this file descriptor has a very large value, but is that really very
likely, especially on a system that doesn't have poll()?
No idea. IIRC the windows select fdset implementation isn't bitfield
based, so there might not be that much an issue with it at all.
Anyway, this (and the following ones) dropped for now.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
