On 19 Jun, 21:41, Carl Banks <pavlovevide...@gmail.com> wrote: > > (Note: I'm not talking about releasing the GIL for I/O operations, > it's not the same thing. I'm talking about the ability to run > computations on multiple cores at the same time, not to block in 50 > threads at the same time. Multiple cores aren't going to help that > much in the latter case.)
There seems to be a mixing together of these two things when people talk about "concurrency". Indeed, on the concurrency-sig mailing list [1] there's already been discussion about whether a particular example [2] is really a good showcase of concurrency. According to Wikipedia, concurrency is about "computations [...] executing simultaneously" [3], not about whether one can handle hundreds of communications channels sequentially, although this topic is obviously relevant when dealing with communications between processing contexts. I agree with the over-rationalisation assessment: it's not convenient (let alone an advantage) for people to have to switch to C so that they can release the GIL, nor is it any comfort that CPython's limitations are "acceptable" for the socket multiplexing server style of solution when that isn't the kind of solution being developed. However, there are some reasonable tools out there (and viable alternative implementations), and I'm optimistic that the situation will only improve. Paul [1] http://mail.python.org/mailman/listinfo/concurrency-sig [2] http://wiki.python.org/moin/Concurrency/99Bottles [3] http://en.wikipedia.org/wiki/Concurrency_(computer_science) -- http://mail.python.org/mailman/listinfo/python-list
