We're now assuming that the size of size_t is a long unsigned integer.
In the kernel there's a comment:
/*
* Most 32 bit architectures use "unsigned int" size_t,
* and all 64 bit architectures use "unsigned long" size_t.
*/
On 32 bit architectures, an unsigned int is the same size as an unsigned
long anyway, so I think this assumption is OK.
Otherwise I get
Error: test_massively_parallel_IP_address_addition(TestAddr::TestWithNetlinkRouteSocket)
Errno::EMFILE: Too many open files - socket(2)
lib/linux/netlink/nlsocket.rb:61:in `initialize'
lib/linux/netlink/nlsocket.rb:61:in `new'
lib/linux/netlink/nlsocket.rb:61:in `initialize'
lib/linux/netlink/route.rb:21:in `initialize'
test/t_route.rb:54:in `new'
test/t_route.rb:54:in `block (4 levels) in <class:TestAddr>'
"pid" is not "process id" in netlink, but rather, "port id". If you bind to a
sockaddr == 0 then Linux automatically assigns your socket a port id - which
happens to be the same as the process ID for the first one concurrently open.
For the second and subsequent concurrently-open sockets, binding 0 (as most
users of this library will do) gets you back a random high-numbered port id.
This change preserves the existing use case (one port open in the process,
binding to 0) while fixing multiple-ports-open-in-the-same-process, socket-is-
passed-in-and-pid-is-not-specified, and specific-pid-is-requested-but-could-
not-bind-to-it.
We're probably still not thread-safe - the seq handling looks dodgy - but at
least now we can use multiple sockets in separate threads and have them all
work.
Using the same socket from multiple threads is a slightly niche use case, and
it's tempting to say "don't do this" instead...
