> For years, there has been a f_tstate field in frames. > > During my implementation of thread pickling for Stackless, > I investigated how much use is made of this field. > I found out that it is only used in rare cases, only, and can > be most probably replaced by PyThreadState_GET() in the > six or seven cases where it is touched at all. > > f_tstate would make sense if PyThreadState_GET() wasn't > such a cheap macro. It also would make sense if it were used > somewhere to assure proper allocation of a frame to its tstate. > But this is nowhere used. > In the case of Stackless, f_tstate turns out to be even a > drawback, since non-recursively called frames can be freely > moved between real threads, and I'm saving updates to f_tstate > already, simply by removing it. > > I also didn't find any external module that uses f_tstate. > > Therefore, I hereby propose to remove this frame field, > in order to save space. > > I also offer to provide the simple patch, right now. I notice that all the places that use f_tstate are functions that get a frame passed in. What makes you believe that those always run in the same thread where the frame was created? --Guido van Rossum (home page: http://www.python.org/~guido/)
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