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