Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Reference counting is also the reason why Python requires a GIL. Incrementing a reference count is an opportunity for a race condition (another thread could read the refcount in between your read and write), which means that every reference count needs to be protected by a lock. Either you do fine-grained locking for each object, or you add a GIL for the whole interpreter. The former will absolutely kill performance (not only do you need to increment a refcount with every assignment or function call, you need to take a lock). The latter makes the whole interpreter thread-hostile.


You're off in the weeds. A refcount can be incremented/decremented with a simple atomic compare-and-swap, and that's exactly what most refcounting systems do.

It's not free, but it's damn close to it.


If that is the case then why doesn't Python do it? I mean this as a real question; I genuinely don't know.


Because it was designed and written poorly, and its thread-safety issues extend far beyond refcounting.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: