> > 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. > > Right, f_tstate is never updated. > I think there is another inconsistent > situation, which can be created easily. > If a generator is run by a different thread > than it's creator, then the frame is run in that > other thread. eval_fame correctly uses tstate, > but if tracing is activated, call_trace uses > frame->f_tstate for no obvious reason, which > will probably mess up the tracing flags of the wrong > thread. Right. Could you dig through CVS logs to find out when f_tstate was first introduced? Maybe there's a clue about why there. --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