Support for multiple interpreters already exists from the C API
(mod_python, Java Embedded Python a few other add-ons use them)
But:
- it's not possible to create new interpreter instances from within Python.
- there's no mechanism for passing information between interpreters.
- interaction with extension modules instances may be a problem.
Apart from these points they actually seem to work pretty well and it might
be, as
you suggest, a "Practical" approach.
Implementing a 'subinterp' module could be interesting...
Max
On 9/30/05, Paul Moore <p.f.moore at gmail.com> wrote:
>
> On 9/30/05, Jim Jewett <jimjjewett at gmail.com> wrote:
> > Bruce Eckel wrote:
> >
> > > 3) Tasks are cheap enough that I can make
> > > thousands of them, ...
> >
> > > 4) Tasks are "self-guarding," so they prevent
> > > other tasks from interfering with them. The
> > > only way tasks can communicate with each
> > > other is through some kind of formal
> > > mechanism (something queue-ish,
> > > I'd imagine).
> >
> > I think these two are the hardest to reconcile.
>
> Agreed. I think the biggest problem is that (4) is too strong. At the
> OS level, certain issues (such as the current directory, or the stdio
> streams) are per-process, so that taking (4) at face value requires
> multiprocessing, which violates (3)...
>
> If you constrain (4), you can get something much more effective. For
> example, if you accept that certain things are volatile (start with
> OS-specified per-process stuff, plus the Python builtins, maybe) then
> it's much easier to produce solutions.
>
> I don't think that shared state is that big an issue per se - after
> all, we're all used to the idea that the contents of a file might
> change "behind our backs". The real issue is not having a *clearly
> defined* shared state.
>
> The big problem with threads is that the shared state is *everything*.
> There's no partitioning at all. Every thread-based abstraction is
> based around threads voluntarily restricting themselves to a limited
> set of "safe" communication operations, and otherwise scrupulously
> avoiding each other's space ("Don't sit there, that's auntie Mary's
> chair"...)
>
> If we had an abstraction (multiple interpreters, anyone?) which still
> had a shared state, but a much smaller one, which was defined clearly,
> such that "unsafe" operations were easy to identify, then day-to-day
> concurrent programming would be a lot easier. Yes, it's still possible
> to break things, but people can do that already by hacking about with
> builtins, or abusing the introspection API, and it's not made Python
> unusable, because they generally don't...
>
> This seems to me to be a perfect case for a "Practicality beats
> Purity" approach.
>
> Paul.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/anothermax%40gmail.com
>
--
flickr: http://www.flickr.com/photos/anothermax/sets
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20050930/4627acfb/attachment.html
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4