Re: solving multi-core Python
[Posted July 8, 2015 by jake]
| From: |
| Nathaniel Smith <njs-e+AXbWqSrlAAvxtiuMwx3w-AT-public.gmane.org> |
| To: |
| Eric Snow <ericsnowcurrently-Re5JQEeQqe8AvxtiuMwx3w-AT-public.gmane.org> |
| Subject: |
| Re: solving multi-core Python |
| Date: |
| Sat, 20 Jun 2015 15:08:40 -0700 |
| Message-ID: |
| <CAPJVwBnsFb-HmDYNgCB-6C-ZKxJTkZR5JWdEdUpYDYt=BDYebQ@mail.gmail.com> |
| Cc: |
| python-ideas <python-ideas-+ZN9ApsXKcEdnm+yROfE0A-AT-public.gmane.org> |
On Jun 20, 2015 2:42 PM, "Eric Snow" <ericsnowcurrently-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> tl;dr Let's exploit multiple cores by fixing up subinterpreters,
> exposing them in Python, and adding a mechanism to safely share
> objects between them.
This all sounds really cool if you can pull it off, and shared-nothing
threads do seem like the least impossible model to pull off. But "least
impossible" and "possible" are different :-). From your email I can't tell
whether this plan is viable while preserving backcompat and memory safety.
Suppose I have a queue between two subinterpreters, and on this queue I
place a list of dicts of user-defined-in-python objects, each of which
holds a reference to a user-defined-via-the-C-api object. What happens next?
-n
_______________________________________________
Python-ideas mailing list
Python-ideas-+ZN9ApsXKcEdnm+yROfE0A@public.gmane.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
