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.
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.
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.
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.
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
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.