Closed Bug 506959 Opened 10 years ago Closed 10 years ago
Execute Statements assumes ms, but calls functions that assume microseconds
AsyncExecuteStatements assumes ms, but calls functions that assume microseconds. Oops.
While I was investigating flickering for bug 504384, I noticed handleResult always getting called with 1 result. So async execute was thinking it ran out of time 1000 times too early and gave the 1 (first) result immediately when it "finally" came in.
Updated us to the new TimeStamp API as well. Also reduced the wait to 75ms from 100ms to allow more time for stuff to process results. We should almost always hit the limit of 15 anyway (for efficient queries).
Attachment #391123 - Flags: review?(bugmail)
Comment on attachment 391123 [details] [diff] [review] v1.0 Would you be cool with spinning off a bug to fix the microsecond/millisecond glitch on 1.9.1?
Attachment #391123 - Flags: review?(bugmail) → review+
I'll generate the 1.9.1 patch now.
Whiteboard: [needs review asuth]
1.9.1 branch patch
Attachment #391168 - Flags: review?(bugmail)
Target Milestone: --- → mozilla1.9.2a1
Comment on attachment 391168 [details] [diff] [review] branch v1.0 Thanks! Verified it passes the 1.9.1 storage tests and our thunderbird gloda async-using tests. (Not that I had doubts, but approval-ers like tests I suspect.)
Attachment #391168 - Flags: review?(bugmail) → review+
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Drivers: Having this patch on 1.9.1 would significantly help performance of Thunderbird's gloda.
Whiteboard: [tb3needs] → [tb3needs][awaiting branch approval]
Comment on attachment 391168 [details] [diff] [review] branch v1.0 Approved for 184.108.40.206. a=ss for release-drivers
Attachment #391168 - Flags: approval220.127.116.11? → approval18.104.22.168+
Whiteboard: [tb3needs][awaiting branch approval] → [tb3needs][needs landing on 191]
Verified for 22.214.171.124 by checking the code.
Strange; this doesn't build for me because the Time* functions aren't in dlldeps.cpp, so they don't end up in xpcom_core.lib/dll...
No longer depends on: 560715
You need to log in before you can comment on or make changes to this bug.