For one of my classes, we got to pick a project of our own choosing that uses multithreading in some way. My initial project wasn’t working out well, so I recently decided to try my luck with a Mozilla idea – making places use a background thread whenever possible. I do believe I’ve just scratched the surface, but I figured I’d share what I’ve gotten so far.
It turns out that the nsIThreadManager is pretty easy to use. Basically, I create a background thread when the nsNavHistory object is created, and shut the thread down when it is destroyed. So far I’m just failing one unit test, and that’s because it’s expecting the api calls to be serial so that the database is updated immediately. This code is neat because I’m doing at least one thing in a more modern manner than what most of our codebase is. I’m using namespacing quite extensively, which is pretty much a foreign concept as far as I can tell. I like it a lot though, and it’s making my code easier to follow.
I did learn some important things while doing what I’ve done so far though:
- Our storage API pretty much sucks when you start to throw threading at it. I fixed the biggest issue in the first patch on my queue, but my fix is hacky at best. Suggestions welcome.
hgwithmqis really awesome when you want to make lots of smaller easier to review patches- Unit tests are awesome when you are refactoring code.
- Our perf results are completely unapproachable if you don’t already know what you are doing. If someone could tell me what if I helped or hurt things (or even how the hell to read the numbers in a useful way), I’d greatly appreciate it. Stats are on this tinderbox for the next 24 hours, and then I don’t know where they go.
I have to do a report for this project, so I’ll be posting that as well when I get closer to being done.
