[Stackless] gsoc - stackless Debugging support

[Richard Tew]

On Sun, Mar 22, 2009 at 6:28 PM, Igor Trindade Oliveira
<igor_trindade at yahoo.com.br> wrote:
> Hello,
>
> I am interested in work on Stackless Debugging support, can you give more
> information?
> What kind of external debugging solutions to support tasklets are you talking
> about?

Now, this is how I tentatively see it.  I may have the wrong idea
about the summer of code workings, or a student may have a better idea
for what they'd like to do, or how they'd do it.


* Project scope

This project also includes profiling support.  But this is not that
much extra work over and above the debugging support

Python has per-thread profiling/debugging hooks, this means that any
code which runs in that thread, gets profiled debugged in a standard
way.  However, Stackless complicates this paradigm.  A thread now has
tasklets running on it, but Stackless is a modified version of Python.
 So we need to use their debugging/profiling support, but we need to
do it in a way which works for tasklets.

The current way it works, is to have code in the tasklet switching
logic which takes care of switching in and out per-tasklet values for
the Python profiling debugging hooks.

This means that all the debugging/profiling code in the standard
library which operates based on the per-thread paradigm and is tasklet
unaware, now does not work properly.   What needs to be done within a
summer of code project is to take a look at this code and to see if
there is a clean way of modifying it so that it is backwards
compatible, but also works naturally with Stackless tasklets, in a
beneficial manner (most likely in Python).

It has been proposed by one person that this per-tasklet hook
switching is not the best approach and that there's a better one.  It
may be that we need to take a good look at what the best
debugging/profiling approaches are, in order to get standard library
functionality usable to profile or debug.  If this is the case, then
the project would also potentially involve altering the Stackless
source code (in C).

* Widening the scope

Now, the debugging/profiling standard library work, given a reasonable
level of competence on the part of the student, should not take all of
the summer of code work period.  I may be wrong, and if so, correct
me.  But I understand summer of code projects to have an expectation
from google of 40 hour weeks, for just under three months.

Given knowledge and moderate experience with the C programming
language and no knowledge of how the debugging/profiling support in
Python works, I would expect a student who learns along the way to
take a month or so to do the debugging/profiling support.  This would
leave extra time, which I assume would need to be gainfully taken up
by widening the scope of this project, for this project to be viable
for Google to approve.

So, a natural extension to this project would be identifying other
debuggers, not included in the standard library, which would benefit
from having Stackless support added.

If I were doing this project, one which comes to mind would be windbg
(http://winpdb.org).  This has a nice interface, and for it to be
extended to make visible running tasklets, the ability to debug them,
and so forth, seems like a nice candidate.  Research on popular and
suitable other or alternative debuggers, given that this would not be
enough extra work or that there are better options, would be the job
of the student.


Anyway, there's some more detail.  Let me know if you have any more questions.

Cheers,
Richard.