|
|
|
|
|
by tomp
2211 days ago
|
|
Python is a trivial special case as it has no concurrency. In a single-threaded language, that indeed makes sense. Multi-threaded RC is extremely tricky to implement efficiently, so unless you can prove there's no cycles (or you don't care it it leaks memory), it makes little sense. |
|
No, it's not hard at all to implement efficiently as long as objects don't cross a thread boundary (and e.g. Nim's older GC used to enforce that condition, an old version of K tracked it and switched to "lock; xadd" to count references when something did cross a thread boundary IIRC, which made it inefficient only for those objects that crossed the boundary which usually weren't many.
It's way simpler than multithreaded mark&sweep, for example. Regardless - it makes a lot of sense. It might not make a lot of sense to you, but it does in general in most contexts.