On Mar 28, 2004, at 5:05 AM, Guido van Rossum wrote: >>> 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. :-) This may screw up the work I'm doing to get the profiler to work transparently with threads. Since I can't promise that the profiler will be in the same thread as the code being profiled, I can't guarantee that PyThreadState_GET() will give the correct thread state, so I grab the thread state from the frame object. Of course, this work is also in the super-early stages of development, so I may go some other direction in the future when I find out that this doesn't work correctly...just pointing out a potential user (victim). -- Nick
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