On Mon, 27 Feb 2023 at 10:42, Jon Ribbens via Python-list <python-list@python.org> wrote: > > On 2023-02-26, Chris Angelico <ros...@gmail.com> wrote: > > On Sun, 26 Feb 2023 at 16:16, Jon Ribbens via Python-list > ><python-list@python.org> wrote: > >> On 2023-02-25, Paul Rubin <no.email@nospam.invalid> wrote: > >> > The GIL is an evil thing, but it has been around for so long that most > >> > of us have gotten used to it, and some user code actually relies on it. > >> > For example, with the GIL in place, a statement like "x += 1" is always > >> > atomic, I believe. But, I think it is better to not have any shared > >> > mutables regardless. > >> > >> I think it is the case that x += 1 is atomic but foo.x += 1 is not. > >> Any replacement for the GIL would have to keep the former at least, > >> plus the fact that you can do hundreds of things like list.append(foo) > >> which are all effectively atomic. > > > > The GIL is most assuredly *not* an evil thing. If you think it's so > > evil, go ahead and remove it, because we'll clearly be better off > > without it, right? > > If you say so. I said nothing whatsoever about the GIL being evil.
You didn't, but I was also responding to Paul's description that the GIL "is an evil thing". Apologies if that wasn't clear. > Yes, sure, you can make x += 1 not work even single-threaded if you > make custom types which override basic operations. I'm talking about > when you're dealing with simple atomic built-in types such as integers. > > > Here's the equivalent with just incrementing a global: > > > >>>> def thrd(): > > ... x += 1 > > ... > >>>> dis.dis(thrd) > > 1 0 RESUME 0 > > > > 2 2 LOAD_FAST_CHECK 0 (x) > > 4 LOAD_CONST 1 (1) > > 6 BINARY_OP 13 (+=) > > 10 STORE_FAST 0 (x) > > 12 LOAD_CONST 0 (None) > > 14 RETURN_VALUE > >>>> > > > > The exact same sequence: load, add, store. Still not atomic. > > And yet, it appears that *something* changed between Python 2 > and Python 3 such that it *is* atomic: I don't think that's a guarantee. You might be unable to make it break, but that doesn't mean it's dependable. In any case, it's not the GIL that's doing this. It might be a quirk of the current implementation of the core evaluation loop, or it might be something unrelated, but whatever it is, removing the GIL wouldn't change that; and it's certainly no different whether it's a global or an attribute of an object. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
