Working with Racer
I’m the first one who gets to break new stuff, and so, here are my impressions from Racer: It’s the greatest invention ever!
What’s that? You say I’m a bit biased because I work at Typemock? You might have a point. So how’s my experience so far?
Here’s how I do it:
Step 1: Open the Racer docs. Yeah, I know, RTFM. The docs specify which APIs are supported, meaning, which APIs Racer intercepts to identify deadlocks.
Step 2: Search for usage of these APIs in the code. Obviously, this is redundant if you know your code. But I’ve taken the opportunity to check out OPC (other people’s code). I learned, for example, that NHibernate (which I have to admit, is my first time looking at it) implements its own lock.
Step 3: Now that I found API usage, I climbed up the code tree to see which objects and methods get called. At this point I also looked for shortcuts – are there any tests that already call these methods?
Step 4: Finally, I wrote some tests for Racer to find deadlocks. Depending on the code I tried both cross-function calls, or running the same method on a couple of threads.
And the results are in. So far I’ve found… nothing. Actually, in NUnit, I didn’t find problems. With NHibernate, I had trouble setting it up, so I decided to let it. I do want to give it another go, though.
I’m going to continue my quest, to find deadlocks in open source projects, and then expose them to the public. (I know they are already exposed because they’re open source, humor me here). So I’m going to pick one project each week, and try it. I’ll post the results I get.
Which project should I pick next? Would you volunteer to run it on your project? You can download a 21-day evaluation now. So race ahead and take Racer for a ride now!