Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #76431

Re: GIL detector

References <53f0ba6c$0$29982$c3e8da3$5496439d@news.astraweb.com>
Date 2014-08-18 00:52 +1000
Subject Re: GIL detector
From Chris Angelico <rosuav@gmail.com>
Newsgroups comp.lang.python
Message-ID <mailman.13069.1408287138.18130.python-list@python.org> (permalink)

Show all headers | View raw


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

Back to comp.lang.python | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

GIL detector Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-18 00:21 +1000
  Re: GIL detector Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-08-17 16:40 +0200
    Re: GIL detector Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-18 01:01 +1000
  Re: GIL detector Chris Angelico <rosuav@gmail.com> - 2014-08-18 00:52 +1000
  Re: GIL detector Stefan Behnel <stefan_ml@behnel.de> - 2014-08-17 17:26 +0200
    Re: GIL detector Grant Edwards <invalid@invalid.invalid> - 2014-08-18 15:05 +0000
  RE: GIL detector "Joseph L. Casale" <jcasale@activenetwerx.com> - 2014-08-17 16:01 +0000
    RE: GIL detector Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-18 02:43 +1000
  Re: GIL detector Chris Angelico <rosuav@gmail.com> - 2014-08-18 02:07 +1000
  Re: GIL detector Chris Angelico <rosuav@gmail.com> - 2014-08-18 02:12 +1000

csiph-web