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

Source/modules/webdatabase/DatabaseContext.h

 /*
  * Copyright (C) 2008 Apple Inc. All Rights Reserved.
  * Copyright (C) 2011 Google, Inc. All Rights Reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
  * are met:
  * 1. Redistributions of source code must retain the above copyright
  *    notice, this list of conditions and the following disclaimer.
  * 2. Redistributions in binary form must reproduce the above copyright
@@ skipping 57 matching lines @@
     bool allowDatabaseAccess() const;
 
     SecurityOrigin* securityOrigin() const;
     bool isContextThread() const;
 
 private:
     explicit DatabaseContext(ExecutionContext*);
 
     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;
     bool m_hasOpenDatabases; // This never changes back to false, even after the database thread is closed.
     bool m_isRegistered;
     bool m_hasRequestedTermination;
 };
 
 } // namespace WebCore
 
 #endif // DatabaseContext_h