STINNER Victor <vstin...@python.org> added the comment:
The idea of immortal objects was proposed to solve the bpo-39511 problem. I dislike immortable for different reasons. Here are some. Gregory: > We wound up not deploying it or pushing for it in CPython because the CPU > performance implications of adding a branch instruction to Py_INCREC and > Py_DECREF were, unsurprisingly, quite high. Exactly. Copy-on-Write problem affects a minority of users. If PR 19474 is enabled by default, all users will pay the overhead even if they never call fork() without exec(). 1.17x slower on logging_silent or unpickle_pure_python is a very expensive price :-( Pablo: > Anything that is touched by the immortal object will be leaked. This can also > happen in obscure ways if reference cycles are created. gc.freeze() has a similar issue, no? This function also comes from Instagram specific use case ;-) Steve: > This isn't actually about removing immortal objects, but removing *mutable* > objects that would be shared between subinterpreters. Making some objects > immortal, such as interned strings or stateless singletons, would actually > benefit this work, as they could then be safely shared between > subinterpreters. >From what I understood, we simply cannot share any object (mutable or not) >between two subinterpreters. Otherwise, we will need to put a lock on all >Py_INCREF/Py_DECREF operation which would kill performances of running >multiple interpreters in parallel. Join bpo-39511 discussion. ---------- nosy: +vstinner _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue40255> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
