Rails thread safety and impact on corporate adoption

Hi All

We all know that Rails is not thread safe.

However I was wondering if DHH and team were taking a look at this, since this will have a heavy impact on RoR’s corporate adoption. Lets face it, no corporate would want to spend many many man hours debugging concurrency related problem and won’t adopt anything that is not thread safe.

Your thoughts …



linux user wrote:

> Lets face it, no corporate would want to spend many many man hours debugging
> concurrency related problem and won't adopt anything that is not thread
> safe.

Really? And why do you think that? While I do agree that thread safety
would be a nice addition to rails, it's far from being the most
important, or the single barring issue to corporate adoption.

Right now rails is simple to code -- the user doesn't have to worry
about concurrency issues, since there's no concurrency at all. And
contrary to what people usually think, that doesn't hinder scaling,
unless we're talking about an application with a -really- high
concurrency level -- the likes we don't see every day.

As closing words, I'm with David on this subject[1]. We don't need
corporate adoption.

[1] http://www.loudthinking.com/arc/000577.html

-- Pazu

i don't really understand why people keep asking about concurrency and
threading issues. you don't normally use threads yourself in a web
application - to do so would be bad practice. any situation in which
your going to need threads is likely to be a long running operation that
you should be handling with an external program that runs on the server,
but not in the webserver. you would then use threading inside that
program and some kind of ipc to send jobs its way, with a status file
the web app can read to determine how things are going, or get the
program to fire off an email message or something. It's not just rails
we're talking about here, its the same for any web application.

Pazu wrote:

Please see the thread that was started yesterday on the same topic.


you probably wouldn't, but the app might at the infrastructure level -- instead of using a cluster of mongrel apps you'd have a single app which spawned threads to handle incoming requests.

the value of this is somewhat debatable: ruby threading isn't particularly fast, so it isn't clear that you'd save anything on speed unless you're ram constrained. on top of that, everyone from dhh to you has to be more careful about concurrency, and if any single thread goes south you take out the entire server process rather than one user request.