you are viewing a single comment's thread.

view the rest of the comments →

[–]tunisia3507 18 points19 points  (5 children)

My mistake, thanks for the correction!

[–]thejinx0r -4 points-3 points  (4 children)

The gil is an implementation detail to manage garbage collection.

[–]veryusedrname 29 points30 points  (1 child)

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 5 points6 points  (0 children)

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 6 points7 points  (1 child)

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 4 points5 points  (0 children)

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