Refactored cookies persistent store clean-up on shutdown.

chrome/browser/net/sqlite_persistent_cookie_store.cc

 // Copyright (c) 2010 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "chrome/browser/net/sqlite_persistent_cookie_store.h"
 
 #include <list>
 
 #include "app/sql/statement.h"
 #include "app/sql/transaction.h"
@@ skipping 422 matching lines @@
   if (backend_.get())
     backend_->UpdateCookieAccessTime(cc);
 }
 
 void SQLitePersistentCookieStore::DeleteCookie(
     const net::CookieMonster::CanonicalCookie& cc) {
   if (backend_.get())
     backend_->DeleteCookie(cc);
 }
 
-// static
-void SQLitePersistentCookieStore::ClearLocalState(
-    const FilePath& path) {
-  file_util::Delete(path, false);
+void SQLitePersistentCookieStore::ClearLocalState() {
+  file_util::Delete(path_, false);

[Mattias Nissler (ping if slow), 2010/12/01 17:23:24]

What's the contract on the question which thread this is safe to call on? Is
there a policy for PersistentCookieStore? If so, should we do an explicit switch
to the FILE thread (if necessary) here?

[Randy Smith (Not in Mondays), 2010/12/01 20:39:50]

This file's somewhat messy WRT thread access.  The basic flow is that
SQLitePersistentCookieStore accesses occur on the IO thread, and database
reads/writes are handed off to the backend, which primarily runs on the DB
thread.  But the initial open of the file appears to occur on the IO thread (in
Load()), which is a no-no.  And, of course, this access was (if I'm reading the
code right) happening on the IO thread before this change.  In an ideal world,
we'd proxy the request over to the FILE thread or (preferably, to reduce the
number of threads the code runs on) the DB thread through the Backend.  But I
wouldn't hold the change hostage to that, as this isn't a regression, but it
isn't correct as (originally) written.

[jochen (gone - plz use gerrit), 2010/12/02 08:45:50]

I think this should be done on the DB thread. Also, you need to make sure that
the sql file is actually closed before you delete it (otherwise it'll fail on
windows)

 }