[Webkit-unassigned] [Bug 27966] Race condition in the database code
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Mon Aug 10 14:13:46 PDT 2009
https://bugs.webkit.org/show_bug.cgi?id=27966
Dumitru Daniliuc <dumi at chromium.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #34363|review? |
Flag| |
Attachment #34363|0 |1
is obsolete| |
Attachment #34512| |review?
Flag| |
--- Comment #17 from Dumitru Daniliuc <dumi at chromium.org> 2009-08-10 14:13:43 PDT ---
Created an attachment (id=34512)
--> (https://bugs.webkit.org/attachment.cgi?id=34512)
same patch
Michael, I think I addressed all your comments, please take another look.
m_lockAcquired: I added ASSERTs at the beginning of every task executed on the
DB thread (+ openTransactionAndPreflight, which used to be and still kind of is
the real first step). I'm also checking this flag in the destructor, and if
it's true, I call releaseLock(). Any reason not to do it? It seems to me like
this approach should work in Chromium's case too. Minor concern: in order to be
able to do this in the destructor, I have to set m_lockAcquired to false
everywhere I call releaseLock() (otherwise releaseLock() will be called in the
destructor again, and some assertions will fail). Is it somehow possible that
releaseLock() is called (and the transaction is taken out of the queue), but
m_lockAcquired is not reset to false right after that? I can't think of any
case that would result in this behavior.
HashMap of collections: I used the same technique that you used in your code,
and cleaned up the destructor. Please double-check that I don't have
"refactoring typos" in this code.
--
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