On Fri, Jul 11, 2014 at 01:01:26AM +0000, Alin Serdean wrote:
> Bypass epoll_ctl, epoll_create and epoll_wait functions on MSVC.
>
> Signed-off-by: Alin Gabriel Serdean <aserd...@cloudbasesolutions.com>
What's the substitute for these on Windows? Maybe it was supposed to
be in this hunk, which appears incomplete and wrong:
> +#else
> + for (int idx = 0; idx < dpif->uc_array_size; ++idx)
> + {
> + struct dpif_channel *ch =
> &dpif->handlers[handler_id].channels[idx];
> +
> +#endif
This patch looks incomplete otherwise, because I see remaining
references to epoll_fd, e.g. in destroy_all_channels():
close(handler->epoll_fd);
and dpif_linux_recv_wait__():
poll_fd_wait(handler->epoll_fd, POLLIN);
By the way, dpif-linux relies on some properties of epoll that aren't
obtained just by waiting on all the individual fds in place of a
single epoll fd. In particular, if thread A calls
dpif_linux_recv_wait(), then blocks in poll_block() waiting for some
packet to be received, and thread B adds or removes ports, thread A
will wake up for packets received on the *updated* set of ports as
modified by thread B. It gets that "for free" because that's how
epoll sets work.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
