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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sat Aug 8 13:42:21 PDT 2009


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





--- Comment #15 from Michael Nordman <michaeln at google.com>  2009-08-08 13:42:18 PDT ---
> > 51         typedef Deque<RefPtr<SQLTransaction> > TransactionsQueue;
> > 52         typedef HashMap<String, TransactionsQueue*> TransactionsHashMap;
> > 53         OwnPtr<TransactionsHashMap> m_pendingTransactions;
> > 
> > Can you use an OwnPtr<TransactionsQueue> in the HashMap to avoid any manual
> > cleanup in the dtor? When the TransactionsHashMap is deleted i think it would
> > all be properly deleted and deferenced.

I think the mapped type can be the collection class (no ptr indirection
involved). The code that operates on the map would have to change to use
iterators to access references to the map elements (instead of making copies of
the elements via the get(key) method. Then there would be no cleanup code
required in the dtor (less code is good). WDYT?

There are examples of HashMap<key, CollectionT> in the code base that you can
look at for examples. DOMApplicationCache's EventListenerMap is one example.

> Again, after some investigation with Michael, we found a case where a
> transaction might fail before it even acquires a lock (Database::stop() is
> called after scheduling the first step of a transaction on the DB thread, but
> before the DB thread has a chance to start the task). So we added a
> m_lockAcquired flag to SQLTransaction.

I think the addition of the flag is a nice and easy way to handle the early
exit case. We could also use the flag to make some assertions about not having
missed other cases provided we reset it upon calling releaseLock() and
ASSERT(!m_lockAcquired) in the dtor. We could also ASSERT(m_lockAcquired) in
the processing of other transaction steps to make sure we haven't missed
acquiring the lock in any cases. WDYT?

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



More information about the webkit-unassigned mailing list