[net (linux)] Don't send OnIPAddressChanged when the AddressMap is first populated.

net/base/address_tracker_linux.cc

Index: net/base/address_tracker_linux.cc
diff --git a/net/base/address_tracker_linux.cc b/net/base/address_tracker_linux.cc
index b97b2b00e0d48ce6615ecf494639b533078f1577..af2a88dafc6da6c15a3deab72a5c7bb3ac49e71a 100644
--- a/net/base/address_tracker_linux.cc
+++ b/net/base/address_tracker_linux.cc
@@ -141,6 +141,9 @@ void AddressTrackerLinux::Init() {
   }
 
   netlink_fd_ = sock;
+
+  // Consume any pending messages to populate the AddressMap, but don't notify.
+  ReadMessages();

[mmenke, 2012/09/04 19:40:16]

Since this is a non-blocking socket, is there a chance that netlink hasn't
answered our first query yet?

[szym, 2012/09/04 20:10:59]

I just tested this and it seems to be working as intended.

I looked through the kernel source code. The entry point is rtnetlink_rcv_msg.
The handler for (PF_UNSPEC, RTM_GETADDR, NLM_F_DUMP) is rtnl_dump_all which
calls through all registered RTM_GETADDR dump handlers. For example:
inet_dump_ifaddr (inet)
int_dump_addr (inet6)
getaddr_dumpit (phonet)
dn_nl_dump_ifaddr (decnet)

So the kernel will create the sk_buff for the whole dump before calling through
netlink_dump_start. netlink_dump cannot fail with anything other than EINVAL,
ENOBUFS, ECONNREFUSED, or EBUSY. It will return EBUSY iff we send another
request while the previous dump is in progress.

So my conclusion is that it will not block until the initial dump is complete.

 }
 
 AddressTrackerLinux::AddressMap AddressTrackerLinux::GetAddressMap() const {