[Python-ideas] solving multi-core Python
Chris Angelico
rosuav at gmail.com
Tue Jun 23 01:59:51 CEST 2015
More information about the Python-ideas mailing list
Tue Jun 23 01:59:51 CEST 2015
- Previous message (by thread): [Python-ideas] solving multi-core Python
- Next message (by thread): [Python-ideas] solving multi-core Python
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Tue, Jun 23, 2015 at 3:03 AM, Gregory P. Smith <greg at krypto.org> wrote: > On Sat, Jun 20, 2015 at 5:42 PM Chris Angelico <rosuav at gmail.com> wrote: >> >> On Sun, Jun 21, 2015 at 7:42 AM, Eric Snow <ericsnowcurrently at gmail.com> >> wrote: >> > * disallow forking within subinterpreters >> >> I love the idea as a whole (if only because the detractors can be told >> "Just use subinterpreters, then you get concurrency"), but this seems >> like a tricky restriction. That means no subprocess.Popen, no shelling >> out to other applications. And I don't know what of other restrictions >> might limit any given program. Will it feel like subinterpreters are >> "write your code according to these tight restrictions and it'll >> work", or will it be more of "most programs will run in parallel just >> fine, but there are a few things to be careful of"? > > > It wouldn't disallow use of subprocess, only os.fork(). C extension modules > can alway fork. The restriction being placed in this scheme is: "if your > extension module code forks from a subinterpreter, the child process MUST > not return control to Python." > > I'm not sure if this restriction would actually be needed or not but I agree > with it regardless. Oh! That's fine, then. Sounds good to me! ChrisA
- Previous message (by thread): [Python-ideas] solving multi-core Python
- Next message (by thread): [Python-ideas] solving multi-core Python
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-ideas mailing list