Concurrency is a Myth in Ruby (and Python)
igvita.com
igvita.com
http://moderator.appspot.com/#15/e=c9&t=ff&q=2f40...
His answer: threading is not worth it, and something Actor-like built on top of the new multiprocessing module should be written eventually. (Pythonic, no?)
I didn't actually read this article because it basically sounds like "this is a myth because of the GIL" which is just downright moronic. I completely disagree with the idea that concurrency is a "myth," I do however believe that it can be more trouble to successfully implement than in other languages designed for concurrency, even if (theoretically) all the tools are there.
What happened in my case is that when using multiprocessing with Django, if a database connection is opened by the main process to make a query that connection is kept open and workers end up using it instead of spawning their own. If I manually close the connection, they all make their own. This isn't sufficient, however, because global imports related to transaction support still manage to step on each other when queries are run concurrently. This turns out to be a pretty rare race condition, but it does happen.
You can read more at the comment here, including my workarounds: http://ericholscher.com/blog/2008/nov/10/announcing-django-c...
I agree that for most cases non-blocking I/O and select()/epoll() makes more sense, but there are cases where true concurrency (threading or multiple processes) is needed and either memory needs to be explicitly shared (IPC is too costly/complex or memory requirement is high) or the cost of spawning a new process is prohibitive (you're dealing with an SLA).
Writing (correct) multi-threaded programs is actually really hard to do. The underlying philosophy of both Ruby and Python is that the programmer's time is more important than the computer's. Using multiple processes instead of threads may require slightly more memory and computation time, but the programmer will spend less time debugging.