On Fri, Jul 20, 2018 at 06:37:49PM +0100, Jonathan Fine wrote: > Hi Steve > > You wrote > > Sorry Jonathan, can you please explain: > > > > - what problem you are solving with this? > > > > - and what's wrong with the existing garbage collector? > > The problem I'm trying to solve doing multi-core reference counting > garbage collection without a GIL.
Perhaps I'm being a bit slow tonight, but that sounds like you're just repeating the solution: "multi-core reference counting garbage collection without a GIL". What problem does that solve? If the quote-unquote "problem" is "get rid of the GIL", there are already at least two implementations of Python without a GIL (IronPython and Jython). Do they solve your problem? If there's some other problem you are trying to solve, you should explain what it is. > As far as I know, we're not yet able > to do efficient multi-core garbage collection using Python. Why would that be an advantage? My understanding is that reference counting is both deterministic and immediate. Shifting the reference counting into another thread so that it becomes non-deterministic and potentially delayed doesn't sound like an advantage to my naive understanding. But then I've never been one to think that threads are the only, or even the best, form of concurrency. I've never understood why so many people care about the GIL. (Perhaps I'm jaundiced from dealing with too many people who honestly believe that the GIL is why their single-threaded code runs slowly. My favourite was the fellow I knew who was so convinced that Python was slow because of the GIL that he moved to Ruby, which also has a GIL and is slower than Python.) -- Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
