<div><span class="gmail_quote">On 9/17/06, <b class="gmail_sendername">Ivan Krstić</b> <<a href="mailto:krstic@solarsail.hcs.harvard.edu">krstic@solarsail.hcs.harvard.edu</a>> wrote:</span></div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br>At present, the Python approach to multi-processing sounds a bit like<br>"let's stick our collective hands in the sand and pretend there's no
<br>problem". In particular, one oft-parroted argument says that it's not<br>worth changing or optimizing the language for the few people who can<br>afford SMP hardware. In the meantime, dual-core laptops are becoming the
<br>standard, with Intel predicting quad-core will become mainstream in the<br>next few years, and the number of server orders for single-core, UP<br>machines is plummeting.</blockquote>
<div> </div>
<div>I agree with you Ivan.</div>
<div> </div>
<div>Even if I won't contribute code or even a design to the solution (because it isn't an area of expertise and I'm still working on encodings stuff) I think that there would be value in saying: "There's a big problem here and we intend to fix it in Python 3000."
</div>
<div> </div>
<div>When you state baldly that something is a problem you encourage the community to experiement with and debate solutions. But I have been in the audience at Python conferences where the majority opinion was that Python had no problem around multi-processor apps because you could just roll your own IPC on top of processes.
</div>
<div> </div>
<div>If you have to roll your own, that's a problem. If you have to select between five solutions with really subtle tradeoffs, that's a problem too.</div>
<div> </div>
<div>Ivan: why don't you write a PEP about this?</div>
<div><br> </div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">* Bite the bullet; write and support a stdlib SHM primitive that works<br>wherever possible, and simply doesn't work on completely broken
<br>platforms (I understand Windows falls into this category). Utilize it in<br>a lightweight fork-and-coordinate wrapper provided in the stdlib.</blockquote>
<div> </div>
<div>Such a low-level approach will not fly. Not just because of Windows but also because of Jython and IronPython. But maybe I misunderstand it in general. Python does not really have an abstraction as low-level "memory" and I don't see why we would want to add it.
</div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">* Introduce microthreads, declare that Python endorses Erlang's<br>no-sharing approach to concurrency, and incorporate something like
<br>candygram into the stdlib.<br><br>* Introduce a fork-and-coordinate wrapper in the stdlib, and declare<br>that we're simply not going to support the use case that requires<br>sharing (as opposed to merely passing) objects between processes.
</blockquote>
<div> </div>
<div>I'm confused on a few levels.</div>
<div> </div>
<div> 1. "No sharing" seems to be a feature of both of these options, but the wording you use to describe it is very different.</div>
<div> </div>
<div> 2. You're conflating API and implementation in a manner that is unclear to me. Why are microthreads important to the Erlang model and what would the API for fork-and-coordinate look like?</div>
<div> </div>
<div>Since you are fired up about this now, would you consider writing a PEP at least outlining the problem persuasively and championing one of the (feasible) options? This issue has been discussed for more than a decade and the artifacts of previous discussions can be quite hard to find.
</div>
<div><br> Paul Prescod</div>
<div> </div>