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()? -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
