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 …
Regards
-daya
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.
jeremy
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.
-faisal