On 26 May 2017 at 23:49, Stephan Houben <stephan...@gmail.com> wrote: > Hi Nick, > > As far as I understand, the (to me) essential difference between your > approach and my proposal is that: > > Approach 1 (PEP-489): > * Single (global) GIL. > * PyObject's may be shared across interpreters (zero-copy transfer) > > Approach 2 (mine) > * Per-interpreter GIL. > * PyObject's must be copied across interpreters. > > To me, the per-interpreter GIL is the essential "target" I am aiming for, > and I am willing to sacrifice the zero-copy for that.
Err, no - I explicitly said that assuming the rest of idea works out well, we'd eventually like to move to a tiered model where the GIL becomes a read/write lock. Most code execution in subinterpreters would then only need a read lock on the GIL, and hence could happily execute code in parallel with other subinterpreters running on other cores. However, that aspect of the idea is currently just hypothetical handwaving that would need to deal with (and would be informed by) the current work happening with respect to the GILectomy, as it's not particularly interesting as far as concurrency modeling is concerned. By contrast, being able to reliably model Communicating Sequential Processes in Python without incurring any communications overhead though (ala goroutines)? Or doing the same with the Actor model (ala Erlang/BEAM processes)? Those are *very* interesting language design concepts, and something where offering a compelling alternative to the current practices of emulating them with threads or coroutines pretty much requires the property of zero-copy ownership transfer. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
