[Python-Dev] Removing the GIL (Me, not you!) (original) (raw)

Brett Cannon brett at python.org
Tue Sep 11 21:30:40 CEST 2007

On 9/11/07, "Martin v. Löwis" <martin at v.loewis.de> wrote:

> It's the interpreter and thread state itself (pystate.h), for the thread > state, also PyThreadStateCurrent. Then there is the GC state, in > particular "generations". There are various caches and counters also. > > > Caches seem like they definitely might be a problem. Would you mind > expanding on this a little? What gets cached and why?

Depends on the Python version what precisely gets cached. Several types preserve a pool of preallocated objects, to speed up allocation. Examples are intobject.c (blocklist, freelist), frameobject.c (freelist), listobject.c (freelist), methodobject.c (freelist), floatobject.c (blocklist, freelist), classobject.c (freelist). Plus there are tons of variables caching string objects. From classobject.c alone: getattrstr, setattrstr, delattrs, docstr, modstr, namestr, initstr, delstr, reprstr, strstr, hashstr, eqstr, cmpstr, getitemstr, setitemstr, delitemstr, lenstr, iterstr, nextstr, getslicestr, setslicestr, delslicestr, contains, all arguments to UNARY, UNARYFB, BINARY, BINARYINPLACE (e.g. instanceneg, instanceor, instanceior, then cmpobj, nonzerostr, indexstr. (admittedly, classobject.c is extreme here). There are probably more classes which I just forgot.

We should probably document where all of these globals lists are instead of relying on looking for all file level static declarations or something. Or would there be benefit to moving things like this to the interpreter struct so that threads within a single interpreter call are locked but interpreters can act much more independently?

-Brett

More information about the Python-Dev mailing list