We’re having a blast in Paris. 5 weeks in the latin quarter was lovely. 5 months in le marais will be too.

Now to find some french lessons.

Congratulations to the rubinius guys on getting our little web framework that could to start up and serve requests. It’s great to see so much experimentation and progress happening in one large and bazaar-like community!

In this day of multi-core CPUs and parallel programming platforms a common meme amongst developers has become “Is library X thread safe?”. As reasonable as that sounds, it’s actually not a particularly interesting question to ask, and anyone who claims to have a useful answer, probably doesn’t know what’s going on. I say that because unless you say what you want to do in parallel, it’s meaningless to say whether or not a library is thread safe.

Take a popular definition of thread safety, this one’s from wikipedia:

A piece of code is thread-safe if it functions correctly during simultaneous execution by multiple threads.

Using that definition, is libevent thread-safe? The answer turns out to be a little more complicated than a yes or no answer, it depends what you’re trying to do in each of those threads.

What about Rails ? Well, strictly speaking Rails is currently thread-safe. It functions correctly during simultaneous execution, we just have this huge mutex around the entire request so we only handle one request at a time. What about Active Record? Well, yes… But it opens a connection per thread which will quickly exhaust your database server’s resources. Both of these restrictions present problems for people wanting to use rails in a highly threaded environment, so perhaps thread safety isn’t a particularly useful goal without further clarification.

It’s just not useful to say whether or not rails ( or any other librarary ) is ‘thread safe’ without saying what you want to do in parallel, the code may function correctly but run slower than it would in a single thread.

With rails there are several different concurrent use cases we could aim to support in our new thread-safety project

• Dispatch requests in parallel with a single thread per request
• Allow rendering to be performed in parallel for a single request (several threads each rendering a seperate partial for the same response)
• Make Active Record use a connection pool to prevent opening an excessive number of connections
• Allow a single Active Record object to be worked with concurrently in multiple threads.

Each of these goals will involved differing numbers of locks, and differing degrees of change to the current design. They’ll also improve (or degrade) performance by different factors for different benchmarks. Whatever the results of this process there will still be some locks around some methods, and those locks are bound to annoy someone.

Phrases like “W is completely threadsafe” or “X isn’t thread safe” should be a red flag to you. They’re a sign that the speaker doesn’t quite understand the subtlety of the question, and the irrelevance of the answer without further qualification.