[Python-Dev] Removing the GIL (Me, not you!) (original) (raw)
"Martin v. Löwis" martin at v.loewis.de
Tue Sep 11 17:50:00 CEST 2007
- Previous message: [Python-Dev] Removing the GIL (Me, not you!)
- Next message: [Python-Dev] Removing the GIL (Me, not you!)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 (block_list, free_list), frameobject.c (free_list), listobject.c (free_list), methodobject.c (free_list), float_object.c (block_list, free_list), classobject.c (free_list).
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, UNARY_FB, BINARY, BINARY_INPLACE (e.g. instance_neg, instance_or, instance_ior, then cmp_obj, nonzerostr, indexstr. (admittedly, classobject.c is extreme here).
There are probably more classes which I just forgot.
Regards, Martin
- Previous message: [Python-Dev] Removing the GIL (Me, not you!)
- Next message: [Python-Dev] Removing the GIL (Me, not you!)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]