Re: Python GIL Thoughts
It's a discussion issue. PEP 554 is trying to focus on the API of subinterpreters and doesn't want to distract from that by bringing the GIL into it. That being said, the general expectation from everyone involved is there will be a perl-interpreter GIL. On Sat, Jun 27, 2020 at 10:31 AM Denis Kotov <redradist@gmail.com> wrote:
Reading PEP554 https://www.python.org/dev/peps/pep-0554/#a-disclaimer-about-the-gil seems like at the current implementation of subinterpretters there will be no separate GIL …
But I am wondering, why ?
Each subinterpreter has it own object management and Garbage Collection …
Why subinterpreters should share one GIL ?
Is there any technical issues ?
Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ZC3WVJ... Code of Conduct: http://python.org/psf/codeofconduct/
Just for clarification, I assume you meant ‘per-interpreter’ there, not ‘Perl-interpreter’ which would be a somewhat more interesting option Steve On Mon, 29 Jun 2020 at 21:48, Brett Cannon <brett@python.org> wrote:
It's a discussion issue. PEP 554 is trying to focus on the API of subinterpreters and doesn't want to distract from that by bringing the GIL into it.
That being said, the general expectation from everyone involved is there will be a perl-interpreter GIL.
On Sat, Jun 27, 2020 at 10:31 AM Denis Kotov <redradist@gmail.com> wrote:
Reading PEP554 https://www.python.org/dev/peps/pep-0554/#a-disclaimer-about-the-gil seems like at the current implementation of subinterpretters there will be no separate GIL …
But I am wondering, why ?
Each subinterpreter has it own object management and Garbage Collection …
Why subinterpreters should share one GIL ?
Is there any technical issues ?
Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ZC3WVJ... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/H5XRPU... Code of Conduct: http://python.org/psf/codeofconduct/
Brett Cannon wrote:
It's a discussion issue. PEP 554 is trying to focus on the API of subinterpreters and doesn't want to distract from that by bringing the GIL into it. That being said, the general expectation from everyone involved is there will be a perl-interpreter GIL. On Sat, Jun 27, 2020 at 10:31 AM Denis Kotov redradist@gmail.com wrote:
Reading PEP554 https://www.python.org/dev/peps/pep-0554/#a-disclaimer-about-the-gil seems like at the current implementation of subinterpretters there will be no separate GIL … But I am wondering, why ? Each subinterpreter has it own object management and Garbage Collection … Why subinterpreters should share one GIL ? Is there any technical issues ? Sent from Mail https://go.microsoft.com/fwlink/?LinkId=550986 for Windows 10
Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ZC3WVJ... Code of Conduct: http://python.org/psf/codeofconduct/
Okay, where is discussions of PEP 554, because I wanted to propose to add `async` API for sub-interpreters in such way using it not required to create new thread, just use event_loop
On Tue, Jun 30, 2020 at 5:26 AM <redradist@gmail.com> wrote:
Brett Cannon wrote:
It's a discussion issue. PEP 554 is trying to focus on the API of subinterpreters and doesn't want to distract from that by bringing the GIL into it. That being said, the general expectation from everyone involved is there will be a perl-interpreter GIL. On Sat, Jun 27, 2020 at 10:31 AM Denis Kotov redradist@gmail.com wrote:
Reading PEP554 https://www.python.org/dev/peps/pep-0554/#a-disclaimer-about-the-gil seems like at the current implementation of subinterpretters there will be no separate GIL … But I am wondering, why ? Each subinterpreter has it own object management and Garbage Collection … Why subinterpreters should share one GIL ? Is there any technical issues ? Sent from Mail https://go.microsoft.com/fwlink/?LinkId=550986 for Windows 10
Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/ZC3WVJ. ..
Code of Conduct: http://python.org/psf/codeofconduct/
Okay, where is discussions of PEP 554, because I wanted to propose to add `async` API for sub-interpreters in such way using it not required to create new thread, just use event_loop
For that specific case you should email the authors of PEP 554.
participants (4)
-
Brett Cannon
-
Denis Kotov
-
redradist@gmail.com
-
Stestagg