[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