On Tue, Jun 30, 2020 at 5:26 AM 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
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
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 wrote:
> It's a discussion issue. PEP 554 is trying to focus on the API of
> subinterpreters and
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
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
On Fri, May 29, 2020 at 02:44:40PM -0400, tritium-l...@sdamon.com wrote:
> These are things that a runtime implementer has to decide on. These are
> also thing that a runtime use gets to complain about. "Don't share data
> amongst threads" is not advice to the cpython user to get truly parallel
On Fri, 29 May 2020 22:18:15 +0300
Paul Sokolovsky wrote:
> In all fairness, I don't know if Stackless ever fully waved GIL
> goodbye. If not, it shows how much the Python userbase needs to get rid
> of GIL.
Yes, nevermind that Stackless was designed at a time when multicore
computers were an
I've just share information, relax ;)
And also it seems like they have very low overhead with atomic variables Arc
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
Hello,
On Fri, 29 May 2020 14:44:40 -0400
wrote:
[]
> These are things that a runtime implementer has to decide on. These
> are also thing that a runtime use gets to complain about. "Don't
> share data amongst threads" is not advice to the cpython user to get
> truly parallel thread
> -Original Message-
> From: Paul Sokolovsky
> Sent: Friday, May 29, 2020 2:26 PM
> To: redrad...@gmail.com
> Cc: python-ideas@python.org
> Subject: [Python-ideas] Re: Python GIL Thoughts
>
> Hello,
>
> On Fri, 29 May 2020 14:19:40 -
> redrad...@
Hello,
On Fri, 29 May 2020 14:19:40 -
redrad...@gmail.com wrote:
> Yesterday RustPython team finished threading without GIL:
> https://github.com/RustPython/RustPython/issues/1831
So what? As was pointed out, there're bunch of Python implementations
which don't use GIL. And it's very
On 2020-05-29 15:19, redrad...@gmail.com wrote:
Yesterday RustPython team finished threading without GIL:
https://github.com/RustPython/RustPython/issues/1831
That first example is Python 2...
___
Python-ideas mailing list --
Yesterday RustPython team finished threading without GIL:
https://github.com/RustPython/RustPython/issues/1831
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
On 26/05/2020 02:42, Steven D'Aprano wrote:
On Mon, May 25, 2020 at 11:11:14AM -,redrad...@gmail.com wrote:
We just need to provide two APIs:
1) Synchronized: `run`, `run_string`, that will wait until thread
notify with setting `atomic variable` in true that it finished
2) Asynchronized
On Mon, May 25, 2020 at 11:19:06AM -, redrad...@gmail.com wrote:
> I like the topic on
> https://www.reddit.com/r/Python/comments/bpp9hg/has_the_python_gil_been_slain_subinterpreters_in/
>
> Answer written by CSI_Tech_Dept:
> ```
> ...
> What probably needs to be done is to have a compile
On Mon, May 25, 2020 at 11:11:14AM -, redrad...@gmail.com wrote:
> We just need to provide two APIs:
> 1) Synchronized: `run`, `run_string`, that will wait until thread
> notify with setting `atomic variable` in true that it finished
> 2) Asynchronized (based on async): `run_async`,
On Mon, May 25, 2020 at 06:38:22PM -0400, Edwin Zimmerman wrote:
> No, there isn't a separate GIL for each sub-interpreter. That would
> be a great feature in my mind, but it isn't there.
I believe that it is a long-term goal to eventually move to a separate
GIL for each subinterpreter:
On 5/25/2020 8:29 AM, redrad...@gmail.com wrote:
> Edwin Zimmerman wrote:
>> On Monday, May 25, 2020 redrad...@gmail.com [mailto:redrad...@gmail.com]
>> wrote
>>> Edwin Zimmerman wrote:
>>> On 5/25/2020 5:56 AM, redrad...@gmail.com
>>> wrote:
>>> Edwin Zimmerman wrote:
>>> Sub-interpreters are a
Edwin Zimmerman wrote:
> On Monday, May 25, 2020 redrad...@gmail.com [mailto:redrad...@gmail.com]
> wrote
> > Edwin Zimmerman wrote:
> > On 5/25/2020 5:56 AM, redrad...@gmail.com
> > wrote:
> > Edwin Zimmerman wrote:
> > Sub-interpreters are a work in progress. The API is not anywhere near
> >
On Monday, May 25, 2020 redrad...@gmail.com [mailto:redrad...@gmail.com] wrote
> Edwin Zimmerman wrote:
> > On 5/25/2020 5:56 AM, redrad...@gmail.com wrote:
> > > Edwin Zimmerman wrote:
> > Sub-interpreters are a work in progress. The API is not anywhere near
> > being finalized.
> > True
redradist＠gmail.com wrote:
> Chris Angelico wrote:
> > On Mon, May 25, 2020 at 7:58 PM redrad...@gmail.com
> > wrote:
> > >
> > Edwin Zimmerman wrote:
> > Only if your workload is CPU bound. Python optimizes IO bound workload
> > performance by
> > releasing the GIL while doing IO. Green threads
Chris Angelico wrote:
> On Mon, May 25, 2020 at 7:58 PM redrad...@gmail.com
> wrote:
> >
> > Edwin Zimmerman wrote:
> > Only if your workload is CPU bound. Python optimizes IO bound workload
> > performance by
> > releasing the GIL while doing IO. Green threads generally do not offer
> > this
Edwin Zimmerman wrote:
> On 5/25/2020 5:56 AM, redrad...@gmail.com wrote:
> > Edwin Zimmerman wrote:
> > Only if your workload is CPU bound. Python optimizes IO bound workload
> > performance by
> > releasing the GIL while doing IO. Green threads generally do not offer
> > this option.
> > Real
On 5/25/2020 5:56 AM, redrad...@gmail.com wrote:
>>> Edwin Zimmerman wrote:
> Only if your workload is CPU bound. Python optimizes IO bound workload
> performance by
> releasing the GIL while doing IO. Green threads generally do not offer this
> option.
>
> Real threads is not needed in Python:
On Mon, May 25, 2020 at 7:58 PM wrote:
>
> >> Edwin Zimmerman wrote:
> Only if your workload is CPU bound. Python optimizes IO bound workload
> performance by
> releasing the GIL while doing IO. Green threads generally do not offer this
> option.
>
> Real threads is not needed in Python:
> 1)
>> Edwin Zimmerman wrote:
Only if your workload is CPU bound. Python optimizes IO bound workload
performance by
releasing the GIL while doing IO. Green threads generally do not offer this
option.
Real threads is not needed in Python:
1) Real threads do not work parallel
2) Real threads only
On 5/23/2020 6:24 PM, redrad...@gmail.com wrote:
> Hi all,
>
> I am very exciting about the sub-interpreters ... but I do not like some
> parts ...
> Consider the following code:
> ```python
> import _xxsubinterpreters as interpreters
> import threading
> import textwrap as tw
> import marshal
>
27 matches
Mail list logo
