> 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). Since the profiler is being invoked from the thread being profiled, how could it end up not being in the same thread? (If I am missing something, I must be missing a *lot* about your design, so you might want to say quite a bit more on how it works.) --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