[Python-ideas] WSAPoll and tulip

Guido van Rossum guido at python.org
Tue Nov 27 17:06:02 CET 2012


I wasn't there, and it's been 7 years since I last saw Visual Studio,
but I do believe it is a decent way to debug C code. But it sounds
like it wa tough to explore the border between C and Python code,
which is why it took you so long to find the issue, right?

Also, please be aware that tulip is *not* ready for anything. As I
just stated in a thread on python-dev, it is just my way of trying to
understand the issues with async I/O (in a different context than
where I've understood them before, i.e. App Engine's NDB). I am well
aware of how hard it is to debug currently -- just read the last
section in the TODO file. I have not had to debug any C code, so my
experience is purely based on using pdb. Here, the one big difficulty
seems to be that it does the wrong thing when it hits a yield or
yield-from -- it treats these as if they were returns, and this
totally interrupts the debug flow. In the past, when I was debugging
NDB, I've asked in vain whether someone had already made the necessary
changes to pdb to let it jump over a yield instead of following it --
I may have to go in and develop a change myself, because this problem
isn't going away.

However, I have noted that a system using a yield-from-based scheduler
is definitely more pleasant to debug than one using yield <future> --
the big improvement is that if the system prints a traceback, it
automatically looks right. However there are still situations where
there's a suspended task that's holding on to relevant information,
and it's too hard to peek in its stack frame. I will be exploring
better solutions once I get back to working on tulip more intensely.

-- 
--Guido van Rossum (python.org/~guido)



More information about the Python-ideas mailing list