[Python-Dev] Re: Useful thread project for 2.5?
python-dev at fromemail.com
Sun Mar 6 23:42:03 CET 2005
Tim Peters wrote:
> Florent's DeadlockDebugger in turn builds on an external C threadframe
> Folding the functionality of that (or similar functionality) into the
> core would, IMO, be a valuable addition for 2.5, and would make an
> excellent intro project for an aspiring contributor interested in how
> threads work in CPython (what this module does is conceptually
> simple). It belongs in the core because it's not safe to chase the
> tstate chain without holding pystate.c's internal head_mutex lock
> (holding the GIL isn't enough -- it's normal practice to call
> PyThreadState_Delete() while not holding the GIL).
> I'd do it myself (and maybe I will anyway), but this really would make
> a good (finite; conceptually simple) project for someone who wants to
> gain Python developer experience.
Since I started this, I might as well finish it. I do have some Python
developer experience (hey, I even voted for comp.lang.python back
when...) but not in the core interpreter itself.
I suspect integrating this feature (let's call it sys._current_frames()
for the sake of argument, although it probably belongs in the threads
module) in the core is not going to be quite as trivial as you say, as
there are potential memory leaks. If the function returns a dictionary,
it should probably be a weak dict to avoid a circular reference between
the frame of the thread that calls _current_frames and its locals that
contain the returned dictionary. But that would also mean the
references to other threads' frames are going to be weak, thus not
allowing the current thread to inspect their locals and backtraces at
will as those weak references may be broken.
Fazal Majid Email: python-dev at fromemail.com
Home: +1 415 359-0918
1111 Jones Apt. 1 Cell: +1 415 244-1337
San Francisco, CA 94109, USA Web: www.majid.info
More information about the Python-Dev