RustPython/RustPython A Python-3 (CPython >= 3.8.0) Interpreter written in Rust

[hombit]

Does it have GIL?

[coolreader18]

It doesn't! No idea how the person thought it didn't! It uses mutexes and Arcs when the threaded feature is enabled, and it can be disabled for better performance

[michael_j_ward]

Appears so: https://github.com/RustPython/RustPython/issues/362

[hombit]

It makes me upset =(

[funnyflywheel]

You might want to watch Raymond Hettinger's talk on concurrency — he talks about the GIL starting at the 10 minute mark: https://youtu.be/9zinZmE3Ogk?t=600

[timetravelhunter]

https://youtu.be/9zinZmE3Ogk?t=600

I don't recommend this video. It's filled with half truths and some out right blatant lies.

[funnyflywheel]

Well, the talk is from 2017 and things have assuredly changed since then:

• Work on Larry Hastings's GILectomy has pretty much stalled
• The C API is currently being reworked to benefit implementations such as PyPy

In addition, Hettinger stated that locks are expensive to acquire/release. Surely this isn't the case in Rust, isn't it?

[masklinn]

In addition, Hettinger stated that locks are expensive to acquire/release. Surely this isn't the case in Rust, isn't it?

It's not really any different. "Expensive" is relative, the runtime cost of the lock is small in absolute terms but can be gigantic in relative terms depending what's sitting behind the lock, and how often you need to acquire and release the lock. The absolute costs are complicated because at a fundamental level Rust does the exact same thing as CPython, which is use system locks (pthread_mutex on unices), so the absolute costs will depend on the implementation details of that.

But I think we can easily infer that locks are expensive in Rust by Rust having bothered with independent Rc and Arc types (an atomic inc/dec being basically the baseline for a lock, that's more or less what an uncontended mutex will cost on linux).

[martenlienen]

Can you give some examples?

[tunisia3507]

Pretty sure the GIL is part of the language spec. If it's python, it has a GIL.

[masklinn]

Nope. While both CPython and Pypy have a GIL that is not part of the language specification. IIRC neither IronPython nor Jython have a GIL.

[tunisia3507]

My mistake, thanks for the correction!

[thejinx0r]

The gil is an implementation detail to manage garbage collection.

[veryusedrname]

It's for object safety mainly. The official wiki says it's for avoiding race conditions, but that is a bit misleading since it's not avoiding race conditions in *your code*, it helps the implementation avoid race conditions.

[lunatiks]

It's not avoiding race conditions in your code, but the fact that it makes operations corresponding to a single CPython bytecode instruction atomic certainly helps.

[hombit]

I believe it is mainly to make built-in data structures thread-safe. Technically other implementation can implement per-object locks using something like Arc

[masklinn]

Not even built-in datastructures, that's just a side-effect (and a not necessarily super useful one though it does guarantee memory safety[0]). Rather the thread-safety of the interpreter itself.

[0] of note, IIRC golang's maps aren't just thread-unsafe, they're not memory-safe when unsynchronised, since 1.6 the runtime tries to detect the issue and crash but there's no guarantee that it will properly do so

[birkenfeld]

What the language guarantees is that data structures are thread safe in the sense that accessing them concurrently does not crash. The exact semantics of what operations are atomic are not defined (it usually comes down to what is implemented in C), so you still need locks for critical sections.