Internally SocketPoll manages the sockets
and handles the polling and firing of callback.
It's thread-safe and handles asynchronous calls
to remove sockets correctly while potentially
being in poll(2).
The choice for using poll(2) compared to epoll
or select are the following:
1. For our use-case, poll(2) works great up to
a few hundred sockets, which we don't expect
to have on a single document normally.
2. select(2) has an awkward API (modifies input,
f.e) and has limit on max fds that we need to
be mindful of (even if we'll not hit it in
practice). poll(2) preserves the input and has
a no-nonsense API that's simple and readable.
3. While select(2) is the most portable, poll(2)
isn't far behind. Yet in practice we'll probably
not support other systems than Linux.
4. epoll(2) starts to scale with hundreds or
thousands of sockets. Meanwhile, it has high
overhead to adding/removing sockets (context
switch to kernel and back). Our typical case
will have a handful to a dozen sockets.
Hardly a justification for epoll's heavy guns.
Change-Id: Idf88257ea85e061a37af29eed21e38655ff43c9b
This is virtually always desirable, since
without it we may fail to bind after recycling
if the previous socket is TIME_WAIT.
However, if a socket is bound to same address
this will not prevent the failure to bind,
and we'll detect that the address/port is busy.
So the advantage is in minimizing recycling time.
Change-Id: Ib3bbbf7065f9822acfbd2d7f8ff3e8951739c0ef
The new socket class is implicitly
non-blocking, streaming, ipv4 socket.
Ipv6 to be added later, as necessary.
Change-Id: I722cc63ea97394d47a50b733c58a69cc1529d815
