On Mon, Aug 18, 2014 at 12:21 AM, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: > The day will come that even the cheapest, meanest entry-level PC will come > standard with 8 cores and the GIL will just be an embarrassment, but today > is not that day. I wonder whether Ruby programmers are as obsessive about > Ruby's GIL?
I'm kinda waiting till I see tons of awesome asyncio code in the wild, but the way I'm seeing things, the world seems to be moving toward a model along these lines: 0) Processes get spawned for any sort of security/protection boundary. Sandboxing Python-in-Python (or any other high level language) just isn't worth the effort. 1) One process, in any high level language, multiplexes requests but uses just one CPU core. 2) Something at a higher level dispatches requests between multiple processes - eg Passenger with Apache. So, if you want to take advantage of your eight cores, you run eight processes, and have Apache spread the load between them. Each process might handle a large number of concurrent requests, but all through async I/O and a single dispatch loop. Even the use of multiple threads seems to be dying out (despite being quite handy when lower-level functions will release the GIL) in favour of the multiple process model. I'm just not sure how, with that kind of model, to have processes interact with each other. It's fine when every request is handled perfectly independently, but what if you want per-user state, and you can't guarantee that one user's requests will all come to the same process? You have to push everything through a single serialized storage vault (probably a database), which is then going to become the bottleneck. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
