Oilpan: Prepare to move DatabaseThread and SQLTransactionCoordinator to Oilpan heap.

Source/modules/webdatabase/DatabaseContext.h

Index: Source/modules/webdatabase/DatabaseContext.h
diff --git a/Source/modules/webdatabase/DatabaseContext.h b/Source/modules/webdatabase/DatabaseContext.h
index 4cf60dd240705dba6351bd847711ffc9f54ab83a..93faf8cca110619ad6d9a9fe65492e59a5cdd074 100644
--- a/Source/modules/webdatabase/DatabaseContext.h
+++ b/Source/modules/webdatabase/DatabaseContext.h
@@ -75,7 +75,7 @@ private:
 
     void stopSyncDatabases();
 
-    RefPtr<DatabaseThread> m_databaseThread;
+    RefPtrWillBePersistent<DatabaseThread> m_databaseThread;

[Mads Ager (chromium), 2014/03/19 09:45:26]

This Persistent is in a ThreadSafeRefCounted class. That means that the last
deref can be from a different thread than the one that allocated this object.
Don't we need a CrossThreadPersistent here so it is safe to destruct it on the
thread that does the last deref?

[tkent, 2014/03/19 23:43:53]

Good point.
DatabaseThread doesn't need to be ThreadSafeRefCounted.  Only this RefPtr holds
a reference count of a DatabaseThread.  So, this CL is safe.
A DatabaseThread object is transferred from a context thread to a database
thread by m_thread->postTask(new Task(WTF::bind(function, this)) in
DatabaseThread.cpp. Ideally this task should have CrossThreadPersistent. However
a raw pointer is ok because DatabaseContext::m_databaseThread has a strong
reference until the database thread is dead.

We might need to add ParamStrorageTraits<RawPtr<T>> to wtf/Functional.h in the
future though it is unnecessary for DatabaseThread.

[Mads Ager (chromium), 2014/03/20 06:24:16]

Thanks for that part of the explanation Kent!

The thing that worries me is not DataBaseThread. Having that in a Persistent
seems fine. The thing that worries me is that DatabaseContext is
ThreadSafeRefCounted. That means that in principle it could be created on one
thread and destructed on another thread which would lead to multi-threaded
access to a Persistent chain which can lead to a corrupted persistent chain. It
therefore seems like this Persistent should be a CrossThreadPersistent so that
it can safely be created on one thread and destructed on another.

Is it guaranteed that the DatabaseContext is destructed on the same thread that
created it?

(In any case, this will be solved when we move DatabaseContext into the heap and
use a Member here instead of the CrossThreadPersistent.)

[Mads Ager (chromium), 2014/03/20 06:26:03]

It probably is. I guess this is the execution context for the database thread
that is destructed at the very end of database thread execution?

[tkent, 2014/03/20 07:50:10]

created it?

Yes.
A DatabaseContext object can be referred by objects in a context thread and
objects in a database thread, and the DatabaseContext object is always outlives
the corresponding database thread. So, m_databasethread is always cleared in the
context thread.

     // The contents of m_openSyncDatabases are raw pointers. It's safe because
     // DatabaseBackendSync is always closed before destruction.
     HashSet<DatabaseBackendBase*> m_openSyncDatabases;