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

Groups > comp.lang.python > #76438

Re: GIL detector

Show key headers only | View raw

On Mon, Aug 18, 2014 at 1:26 AM, Stefan Behnel <stefan_ml@behnel.de> wrote:
> I actually wonder more whether Python programmers are really all that
> obsessive about CPython's GIL. Sure, there are always the Loud Guys who
> speak up when they feel like no-one's mentioned it for too long, but I'd
> expect the vast majority to be just ok with the status quo and not think
> about it most of the time. Or, well, think about it when one of the Loud
> Guys takes the megaphone, but then put their thoughts back in the attic and
> keep doing their daily work.
>
> Personally, I like the GIL. It helps me keep my code simpler and more
> predictable. I don't have to care about threading issues all the time and
> can otherwise freely choose the right model of parallelism that suits my
> current use case when the need arises (and threads are rarely the right
> model). I'm sure that's not just me.

The GIL doesn't prevent threads, even. It just affects when context
switches happen and what can run in parallel. As I've often said,
threads make fine sense for I/O operations; although that may start to
change - I'm sure the day will come when asyncio is the one obvious
way to do multiplexed I/O in Python.

The GIL means you can confidently write code that uses CPython's
refcounting mechanisms (whether overtly, in an extension module, or
implicitly, by just doing standard Python operations), and be
confident that internal state won't be corrupted... or, more
accurately, be confident that you're not paying a ridiculous
performance penalty (even in a single-threaded program) for the
guarantee that internal state won't be corrupted. Pike has a similar
global lock; so, I believe, does Ruby, and so do several other
languages. It's way more efficient than a lot of the alternatives. I
can't speak for Ruby, but Pike has had periodic discussions about
lessening the global lock's impact (one such way is isolating
purely-local objects from those with global references; if an object's
referenced only from the execution stack, there's no way for any other
thread to see it, ergo it's safe to work with sans locks - considering
that a lot of data manipulation will be done in this way, this could
give a lot of parallelism), and yet the GIL still exists in Python and
Pike, because it really is better than the alternatives - or at least,
insufficiently worse to justify the transitional development.

We do not have a problem here.

ChrisA

Back to comp.lang.python | Previous | Next — Previous 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