On 2023-02-25, Paul Rubin <no.email@nospam.invalid> wrote: > Jon Ribbens <jon+use...@unequivocal.eu> writes: >>> 1) you generally want to use RLock rather than Lock >> Why? > > So that a thread that tries to acquire it twice doesn't block itself, > etc. Look at the threading lib docs for more info.
Yes, I know what the docs say, I was asking why you were making the statement above. I haven't used Lock very often, but I've literally never once in 25 years needed to use RLock. As you say, it's best to keep the lock-protected code brief, so it's usually pretty obvious that the code can't be re-entered. >> What does this mean? Are you saying the GIL has been removed? > > Last I heard there was an experimental version of CPython with the GIL > removed. It is supposed to take less of a performance hit due to > INCREF/DECREF than an earlier attempt some years back. I don't know its > current status. > > 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. -- https://mail.python.org/mailman/listinfo/python-list
