[Webkit-unassigned] [Bug 29115] Allow multiple read transactions to run concurrently on the same DB thread

[bugzilla-daemon at webkit.org]

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





--- Comment #10 from Michael Nordman <michaeln at google.com>  2009-09-17 21:54:24 PDT ---
> > > while ((pt_it->get() != transaction) && (pt_it->get()->isReadOnly()) && (++pt_it, 1));
> > > ASSERT(pt_it->get() == transaction);
> > 
> > Since the iteration can't fail to find your transaction, according to the
> > ASSERT, I don't think you need to test for end() in your while loop. Also, that
> > while loop is a bit much to parse... (hmmm, what does (foo, 1) mean :)
> 
> i don't think checking for end() is redundant. if we have a bug in this code
> and the transaction was somehow deleted before releaseLock() is called, i think
> it's better to fail the assertion than to get an unexpected crash in the while
> loop.

oh... wait... i missed this.

If there's a bug, we should fix it. Either the assertion holds or it doesn't,
which is it? And if it doesn't hold than shouldn't there be code for that case?

 92         TransactionsQueue::iterator pt_it =
info.pendingTransactions.begin();
 93         while ((pt_it != info.pendingTransactions.end()) && (pt_it->get()
!= transaction) && (pt_it->get()->isReadOnly()))
 94             ++pt_it;
 95         ASSERT(pt_it->get() == transaction);
 96         info.pendingTransactions.remove(pt_it);

Also webkit style issues. I'm not sure what webkit style says about parens,
certainly that last condition doesn't need them. I am sure webkit style frowns
upon abbr_undbr naming. I think you need to take a pass thru this patch for
style'isms.  What does webkit style say about non-const references like this?
CoordinationInfo& info = it->second;

If you had a private helper method to return a CoordiationInfoMap* given a
dbIdentifier, I think that could help because you'd only have one it(erator) to
be concerned with, and no non-const references involved.

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