We’re working on a project using Ruby on Rails 2.0.2 currently.
As you probably know, RoR is not thread-safe. But even if you are not using ActiveRecord, ActionPack nor any other Rails part you still might run into some problems if you thread.
We use the probably most common setup – small loop launching threads to query some web services in parallel. This seemed safe, as it would not use any of RoR classes/modules.
Now here’s the gotcha – automatic constant resolver (part of ActiveSupport) that loads classes from properly named files. It’s a part of RoR too…. and has threading problems, just like the rest of RoR. If a constant is not known before the threads launched, every thread would try to load that constant on its own; only the first thread would succeeded, all the other would raise “constant X is not unknown” exception.
Currently we worked this around by requiring files defining all dependencies in the file that launches the thread before going parallel. It’s ugly and not easily maintainable, as threads use different functions, each with it’s own dependencies – but it works, for now.
Perhaps it’s time to port that project to python – it has proper thread support (not to mention the fact that I wouldn’t have to deal with RoR worst part, that is ActiveRecord – SqlAlchemy is way better)
