[Python-3000] Kill GIL?
krstic at solarsail.hcs.harvard.edu
Mon Sep 18 11:07:56 CEST 2006
Paul Prescod wrote:
> I think that there would be value in saying: "There's a
> big problem here and we intend to fix it in Python 3000."
I'm not at all convinced that this is something to be addressed in 3.0.
Py3k is about removing cruft, not adding features; a proper MP system
represents a feature addition that might be more appropriate for 2.6 or
post-3.0 if it gets horribly drawn out.
> Ivan: why don't you write a PEP about this?
I'd like to hear Guido's overarching thoughts on the matter, if any, and
would afterwards be happy to write a PEP.
> Python does not really have an abstraction as low-level
> "memory" and I don't see why we would want to add it.
You don't need a special abstraction; a library adding primitives like
SHMlist and SHMdict would be fully adequate. Arbitrary objects could
decide to react to specific getattr/setattribute calls by peeking and
poking at the primitives. A SHMpickle mechanism could be used to stuff
existing objects into SHM, and then create relevant proxies.
> 1. "No sharing" seems to be a feature of both of these options, but the
> wording you use to describe it is very different.
Erlang's shared-nothing is a conviction: "you don't need to share things
to get good concurrent operation". The alternative I mention is to
declare "well, we recognize the need for shared-something, but are
pointedly not providing the functionality". An irrelevant difference for
the most part.
> 2. You're conflating API and implementation in a manner that is unclear
> to me. Why are microthreads important to the Erlang model
They're not; Candygram proves as much. But the Erlang model was designed
with the idea that threads ("processes") cost almost nothing, and if
threads instead cost at least a full stack allocation, it's easy to get
into hot water.
> and what would
> the API for fork-and-coordinate look like?
I'm not going to try and design an API at 5:05AM. I'll think about this
in the next few days, and stick it in the PEP after Guido chimes in.
> 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?
Ivan Krstić <krstic at solarsail.hcs.harvard.edu> | GPG: 0x147C722D
More information about the Python-3000