Switch MessagePumpForIO to use completion ports on Windows.

Cleanup the separation between MessagePumpForUI and 
MessagePumpForIO, and convert the latter to use Completion
Ports instead of MsgWaitForMultipleobjects to sleep
when idle.

Remove all traces of Windows messages from MessagePumpForIO,
remove the transitional API of completion port notifications
and remove WatchObject API.

Modify all callers of RegisterIOHandler so that they are no
longer using RegisterIOContext, and also handle properly
the new semantics of completion ports (notifications even when
the IO completes immediately).

Add a new interface to allow proper cleanup of disk cache (to
replace code that was waiting for pending APCs from the destructor).

Add a way for the message pump to perform cleanup of abandoned IO.


BUG=B/1344358, 3497, 3630
TESt=unit tests
R=darin


Review URL: http://codereview.chromium.org/8156

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5021 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 14 insertions, 25 deletions

diff --git a/net/disk_cache/entry_impl.cc b/net/disk_cache/entry_impl.cc
index 844ff40..2821540 100644
--- a/net/disk_cache/entry_impl.cc
+++ b/net/disk_cache/entry_impl.cc
@@ -16,25 +16,8 @@ using base::TimeDelta;
 
 namespace {
 
-// This is a simple Task to execute the callback (from the message loop instead
-// of the APC).
-class InvokeCallback : public Task {
- public:
-  InvokeCallback(net::CompletionCallback* callback, int argument)
-      : callback_(callback), argument_(argument) {}
-
-  virtual void Run() {
-    callback_->Run(argument_);
-  }
-
- private:
-  net::CompletionCallback* callback_;
-  int argument_;
-  DISALLOW_EVIL_CONSTRUCTORS(InvokeCallback);
-};
-
-// This class implements FileIOCallback to buffer the callback from an IO
-// operation from the actual IO class.
+// This class implements FileIOCallback to buffer the callback from a file IO
+// operation from the actual net class.
 class SyncCallback: public disk_cache::FileIOCallback {
  public:
   SyncCallback(disk_cache::EntryImpl* entry,
@@ -57,10 +40,8 @@ class SyncCallback: public disk_cache::FileIOCallback {
 void SyncCallback::OnFileIOComplete(int bytes_copied) {
   entry_->DecrementIoCount();
   entry_->Release();
-  if (callback_) {
-    InvokeCallback* task = new InvokeCallback(callback_, bytes_copied);
-    MessageLoop::current()->PostTask(FROM_HERE, task);
-  }
+  if (callback_)
+    callback_->Run(bytes_copied);
   delete this;
 }
 
@@ -556,9 +537,11 @@ void EntryImpl::DeleteData(Addr address, int index) {
     if (files_[index])
       files_[index] = NULL;  // Releases the object.
 
-    if (!DeleteCacheFile(backend_->GetFileName(address)))
+    if (!DeleteCacheFile(backend_->GetFileName(address))) {
+      UMA_HISTOGRAM_COUNTS(L"DiskCache.DeleteFailed", 1);
       LOG(ERROR) << "Failed to delete " << backend_->GetFileName(address) <<
                     " from the cache.";
+    }
   } else {
     backend_->DeleteBlock(address, true);
   }
@@ -711,7 +694,6 @@ bool EntryImpl::ImportSeparateFile(int index, int offset, int buf_len) {
   return true;
 }
 
-
 // The common scenario is that this is called from the destructor of the entry,
 // to write to disk what we have buffered. We don't want to hold the destructor
 // until the actual IO finishes, so we'll send an asynchronous write that will
@@ -744,6 +726,13 @@ bool EntryImpl::Flush(int index, int size, bool async) {
   if (!file)
     return false;
 
+  // TODO(rvargas): figure out if it's worth to re-enable posting operations.
+  // Right now it is only used from GrowUserBuffer, not the destructor, and
+  // it is not accounted for from the point of view of the total number of
+  // pending operations of the cache. It is also racing with the actual write
+  // on the GrowUserBuffer path because there is no code to exclude the range
+  // that is going to be written.
+  async = false;
   if (async) {
     if (!file->PostWrite(user_buffers_[index].get(), len, offset))
       return false;