[Webkit-unassigned] [Bug 27966] Race condition in the database code

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=27966





--- Comment #4 from Michael Nordman <michaeln at google.com>  2009-08-06 16:39:03 PDT ---
I'm not a webkit reviewer... some drive by comments all the same :)

50         OwnPtr<HashMap<String, Deque<SQLTransaction*>*> >
m_pendingTransactions;

I think you could put RefPtr<T>'s in the Deque to eliminate the manual
refcounting.

51         Mutex m_pendingTransactionsGuard;

I think this should only be called on a particular DB thread, is the Mutex
really needed?

47 SQLTransactionCoordinator::~SQLTransactionCoordinator()
48 {
49 }

What happens to transactions that don't actually start prior to the thread
being killed. How do they get derefed?

210 void SQLTransaction::lockAquired()
211 {
212     m_nextStep =
&SQLTransaction::deliverOpenTransactionAndPreflightCallback;
213     LOG(StorageAPI, "Scheduling deliverOpenTransactionAndPreflight for
transaction %p\n", this);
214     m_database->scheduleTransactionCallback(this);
215 }

A the lockAcquired point, the system pings-pongs to the main thread and back
again to the db thread. What is the reason for the
'deliverOpenTransactionAndPreflightCallback' step? I'm wondering if we can we
skip straight to the openTransactionAndPreflight step at this point, without
ping/ponging to the main thread.


217 void SQLTransaction::deliverOpenTransactionAndPreflightCallback()
218 {
219     m_nextStep = &SQLTransaction::openTransactionAndPreflight;
220     LOG(StorageAPI, "Scheduling openTransactionAndPreflight for transaction
%p\n", this);
221     m_database->scheduleTransactionStep(this);
222 }

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.