[Christian] > >>since I didn't get *any* reply to this request, > >>either the request was bad or there is really > >>nobody using f_tstate in a way that makes it > >>urgent to keep. > >>I will wait a few hours and then make the change > >>to Stackless, and I'd like to propose to do the > >>same to the Python core. [Guido] > > I saved the message, but haven't had the time yet to think things > > through. > > > > I *did* notice at least one case where using f_tstate might actually > > be a mistake: theoretically it's possible that two or more threads > > alternate calling next() on a generator (if they wrap it in a critical > > section); AFAICT the f_tstate is never updated. [Christian] > I've been running Stackless Python without f_tstate for more than > three months now, in various applications. > May I check in a patch to evict f_tstate? Sure! Let stackless lead the way. :-) --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