
On Wed, Feb 16, 2022 at 8:45 PM Inada Naoki <songofacandy@gmail.com> wrote:
Is there any common tool that utilize CoW by mmap? If you know, please its link to the PEP. If there is no common tool, most Python users can get benefit from this.
Sorry, I'm not aware of any, but I also haven't researched the topic much. Regardless, that would be a good line of inquiry. A reference like that would probably help make the PEP a bit more justifiable without per-interpreter GIL. :)
Generally speaking, fork is a legacy API. It is too difficult to know which library is fork-safe, even for stdlibs. And Windows users can not use fork. Optimizing for non-fork use case is much better than optimizing for fork use cases.
+1
I hope per-interpreter GIL replaces fork use cases.
Yeah, that's definitely one big benefit.
But tools using CoW without fork also welcome, especially if it supports Windows.
+1
Anyway, I don't believe stopping refcounting will fix the CoW issue yet. See this article [1] again.
[1] https://instagram-engineering.com/dismissing-python-garbage-collection-at-in...
That's definitely an important point, given that the main objective of the proposal is to allow disabling mutation of runtime-internal object state so that some objects can be made truly immutable. I'm sure Eddie has some good insight on the matter (and may have even been involved in writing that article). Eddie?
Note that they failed to fix CoW by stopping refcounting code objects! (*) Most CoW was caused by cyclic GC and finalization caused most CoW.
That's a good observation!
(*) It is not surprising to me because eval loop don't incre/decref most code attributes. They borrow reference from the code object.
+1
So we need a sample application and profile it, before saying it fixes CoW. Could you provide some data, or drop the CoW issue from this PEP until it is proved?
We'll look into that. -eric