Firefox3/StatusMeetings/2007-12-18

« previous week | index | next week »

Firefox 3/Gecko 1.9 Meeting Details

• Tuesdays - Firefox 3 - 11:00am Pacific, 2:00pm Eastern, 19:00 UTC
• Mozilla Building S - Central Area
• 650-903-0800 or 650-215-1282 x91 Conf# 217 (US/INTL)
• 1-800-707-2533 (pin 369) Conf# 217 (US)
• irc.mozilla.org #granparadiso for backchannel

Schedule & Tree Rules

• • new checkin rules
  • prioritize the blockers, new milestone definitions

Gecko Blockers and Noms charts:

• Blockers
• Stacked Blockers
• Noms
  • Recent Noms (better scaling)
• Stacked Noms
  • Stacked Recent Noms (better scaling)

Gecko Priority Level charts:

• Blockers by Priority
• Blockers by Priority-stacked

Work in progress

Firefox 3

• Places
  • Beta 3: 26 P1/P2 blockers (P1:4, P2:26)

Security Reviews

• Design Review Proposal
• Still needed
  • Microformats (mkaply)
  • Malware Protection (dcamp)
  • Distribution/Customization (thunder)

• Completed
  • Password Manager (done)
  • Offline Apps (done)
  • Web Content Handlers (done)
  • Add-Ons (rob_strong) (done)
  • Places (dietrich/sspitzer) (done)
  • Cross-domain XMLHttpRequest - Done.
  • ContentEditable (peterv) - Done.

General Discussion

mozStorage Database Corruption/Functionality Issues (bug 402615)

I'll try to include as much as possible here since I won't be on call. We've been seeing more and more database corruption/functionality bugs. bug 402615 has some bugs depending on it that are these corruption instances. I've seen at least one other bug go by that I don't have time to search for. These issues are real, and I suspect we'll be getting lots of more them once we start getting more users using our product. It is my belief that this issues would be better identified by removing the async IO that we do on a worker thread.

These issues have a common situation where once something starts to fail, everything is (because async IO got an error at some point, anything it does after that point will fail). If we get rid of this, the original call (like mozStorageConnection::ExecuteStep & friends) would be the one that fails, and the caller has an opportunity to recover.

There is, of course, a down side to removing our async IO. It was added in bug 326334 to help perf. I have not done any tests to see if this is still relevant (vlad would probably be the person to ask for more details on this). If someone wants to see if this is still a serious issue with our perf numbers, there are three lines of code that can be commented out that will disable async IO (this is untested, so I don't know if it compiles):

• http://mxr.mozilla.org/seamonkey/source/storage/src/mozStorageService.cpp#172
• http://mxr.mozilla.org/seamonkey/source/storage/src/mozStorageService.cpp#99
• http://mxr.mozilla.org/seamonkey/source/storage/src/mozStorageConnection.cpp#187

On a side note, if we get rid of async IO, I suspect it would be fairly trivial to upgrade to the latest version of SQLite (3.5.4 - we are running 3.4.1). 3.5 provides us with concurrent reads and writes with the shared cache, which we can't do now (requires adding some threadsafety to mozStorageConnection & friends, but that's not terribly difficult). Having concurrent access on db connections means that we can fix perf hot-spots by having that bit of code write to the DB on a worker thread.