I'll answer myself :-) For UDP the second uv_udp_bind on dup()ed uv_udp_t->fd will always fail (because the socket is already bound), so it's just a matter of setting the correct internal flags on the second and further handle and then starting the uv_udp_start_read() works.
For TCP it's a similar situation with bind, but the epoll will wake up only one thread (probably the first numerically), so there must exist a mechanism to wake up the other threads to call uv_accept() on the shared listening socket. I have yet to write complete proof of concept, but this is the basics. Ondrej On Monday, 30 November 2020 at 17:44:52 UTC+1 Ondřej Surý wrote: > Hey all, > > so I have this a bit out-of-ordinary question - as far as I understand it, > on systems where SO_REUSEPORT_LB (or SO_REUSEPORT on Linux) is not > available, is there any method how to let multiple UDP and/or TCP handles > to listen and compete over a single socket? > > So, I tried few obvious things: > > - Passing same fd to uv_udp_open() doesn't work because uv__fd_exists check > - Calling dup() on the socket and then doing uv_udp_open(..., fd) doesn't > work for me on Linux (if I fake the non-existence of the socket option) and > I get ENOMEM (what?); maybe it's just a problem doing this on Linux and it > will work on freebsd11 / openbsd / netbsd > > Anybody has some other idea I missed? > > Ondrej > -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to libuv+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/libuv/e2b81d99-ea9b-41d4-9091-2307ca07dc8an%40googlegroups.com.
