+1 for overall idea. Some comments:
> > Also note that "fork" isn't the only operating system mechanism > that uses copy-on-write semantics. > Could you elaborate? mmap, maybe? Generally speaking, fork is very difficult to use in safe. My company's web apps load applications and libraries *after* fork, not *before* fork for safety. We had changed multiprocessing to use spawn by default on macOS. So I don't recommend many Python users to use fork. So if you know how to get benefit from CoW without fork, I want to know it. > > Immortal Global Objects > ----------------------- > > The following objects will be made immortal: > > * singletons (``None``, ``True``, ``False``, ``Ellipsis``, ``NotImplemented``) > * all static types (e.g. ``PyLong_Type``, ``PyExc_Exception``) > * all static objects in ``_PyRuntimeState.global_objects`` (e.g. identifiers, > small ints) > > There will likely be others we have not enumerated here. > How about interned strings? Should the intern dict be belonging to runtime, or (sub)interpreter? If the interned dict is belonging to runtime, all interned dict should be immortal to be shared between subinterpreters. If the interned dict is belonging to interpreter, should we register immortalized string to all interpreters? Regards, -- Inada Naoki <songofaca...@gmail.com> _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/DQV6ECSUB2VD2EXX6CVCC45RJA6NR2ZZ/ Code of Conduct: http://python.org/psf/codeofconduct/
