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 _PyThreadState_Current. 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. 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4