GIL detector

[Chris Angelico]

On Mon, Aug 18, 2014 at 12:21 AM, Steven D'Aprano
<steve+comp.lang.python at 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