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