Store callback in DhcpPacFileFetcherChromeos.
The //net idiom for async calls is that they take a callback, and either * return ERR_IO_PENDING, and later call this callback (unless cancelled), or * return something other than ERR_IO_PENDING and never call the callback. DhcpPacFileFetcherChromeos has a Fetch() method which always returns asynchronously. This class creates a PacFileFetcher, and in its ContinueFetch() method calls Fetch() on this PacFileFetcher. PacFileFetcher::Fetch() can return synchronously or asynchronously. In the former case, DhcpPacFileFetcherChromeos must call the callback, in the latter case, PacFileFetcher will. Currently this is implemented by calling AdaptCallbackForRepeating() in DhcpPacFileFetcherChromeos::ContinueFetch(), which turns the OnceCallback into a RepeatingCallback so that it can be passed in to PacFileFetcher::Fetch() while also retained. However, AdaptCallbackForRepeating() is not meant to be used other than temporarily for transitioning from Callback to OnceCallback (which is exactly what we are doing). This CL makes DhcpPacFileFetcherChromeos save the callback in a private member, and passes in a bound method to PacFileFetcher::Fetch(). This way there is no need to use AdaptCallbackForRepeating(). If DhcpPacFileFetcherChromeos::Fetch() is cancelled (Cancel() is called or the class instance is destroyed), then PacFileFetcher is appropriately notified and/or destroyed, so the (invalidated) callback is never run. This is a follow-up to https://crrev.com/c/1066291/9/chromeos/network/dhcp_pac_file_fetcher_chromeos.cc#94. Bug: 730593, 807724 Change-Id: Ic9597114bf54893a98990d56bdb1682cbf4aef5f Reviewed-on: https://chromium-review.googlesource.com/1073192 Commit-Queue: Bence Béky <bnc@chromium.org> Reviewed-by:Steven Bennetts <stevenjb@chromium.org> Cr-Commit-Position: refs/heads/master@{#562083}
Showing
Please register or sign in to comment