[Webkit-unassigned] [Bug 29115] Allow multiple read transactions to run concurrently on the same DB thread
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Thu Sep 17 11:05:24 PDT 2009
https://bugs.webkit.org/show_bug.cgi?id=29115
--- Comment #3 from Dumitru Daniliuc <dumi at chromium.org> 2009-09-17 11:05:22 PDT ---
(In reply to comment #2)
> > m_pendingTransactions.add(dbIdentifier, pendingTransactions);
> > it = m_pendingTransactions.find(dbIdentifier);
>
> Looks like map.add() will return an iterator for you. So you don't have to call
> find() again.
good catch! fixed.
> > 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.
(a, b, ..., y, z) is equivalent to
a;
b;
...
y;
return z;
don't you love C++? :)
> while ((pt_it->get() != transaction) && pt_it->get()->isReadOnly())
> ++pt_it
>
> The logic looks good to me.
i changed it to this, but i kept the (pt_it != pendingTransactions.end()) check
too.
--
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