[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 #12 from Dumitru Daniliuc <dumi at chromium.org>  2009-09-18 11:47:58 PDT ---
> 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);

removed the check for pt_it != info.pendingTransactions.end(). i'm not very
happy about this: if at a later time we somehow introduce a bug in this code,
it will result in seg faults. however, ASSERTs are no-ops in release builds and
i'm not sure if there's anything better than crashing the app that we can do
when we don't find the transaction in this list.

> Also webkit style issues. I'm not sure what webkit style says about parens,
> certainly that last condition doesn't need them.

removed.

> I am sure webkit style frowns upon abbr_undbr naming. I think you need to take a pass thru this patch for
> style'isms.

done.

< 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.

un-abbreviated the iterator variables.

i don't think webkit's style guide says anything about non-const references. in
any case, it seems to me like a legitimate way to modify some data "in place".

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