[Python-Dev] Re: Useful thread project for 2.5?

[Fazal Majid]

Tim Peters wrote:
> Florent's DeadlockDebugger in turn builds on an external C threadframe 
> module:
>
>     http://www.majid.info/mylos/stories/2004/06/10/threadframe.html
>
> 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