[Python-ideas] WSAPoll and tulip

[Trent Nelson]

On Tue, Nov 27, 2012 at 06:42:04AM -0800, Antoine Pitrou wrote:
> 
> Hi,
> 
> Le Tue, 27 Nov 2012 07:33:25 -0500,
> Trent Nelson <trent at snakebite.org> a écrit :
> >     So, it basically works.  poll() on Windows, who would have
> > thought.
> > 
> >     It's almost impossible to test with our current infrastructure;
> > all our unit tests seem to pass pipes and other
> > non-Winsock-backed-socks to poll(), which, like select()-on-Windows,
> > isn't supported.
> 
> Well, then you should write new tests that don't rely on pipes.
> There's no reason it can't be done, and there are already lots of
> examples of tests using TCP sockets in our test suite. It will also be
> a nice improvement to the current test suite for Unix platforms.

    Agreed, there's more work required.  It's on the list.

> >     Visual Studio's debugger to try figure out what the heck was going
> >     on.  I believe the `yield from` aspect made that so much more of
> > an arduous affair -- one moment I'm in selectmodule.c's getaddrinfo(),
> >     then I'm suddenly deep in the bowels of some cryptic eval frame
> >     black magic, then one 'step' later, I'm over in some completely
> >     different part of selectmodule.c, and so on.
> 
> I'm not sure why you're using Visual Studio to debug Python code?
> It sounds like you want something higher-level, e.g. Python print()
> calls or pdb.

    Ah, right.  So, I was trying to figure out why poll was barfing up
    an WSAError on whatever it was being asked to poll.  So, I set out
    to find what it was polling, via breakpoints in register().

    That pointed to an fd with value 3.  That seemed a little strange,
    as all my other socket tests consistently had socket fd values above
    250-something.

    So, I wanted to track down where that fd was coming from, thinking
    it was related to the first poll()/register() instance I could find
    in getaddrinfo().  It wasn't, and through combined use of *both* pdb
    and VS, I eventually stumbled onto the attempt to poll os.pipe()
    FDs.  I think.

    (There were also other issues that I skipped over in the e-mail;
     like figuring out I had to &= ~POLLPRI in order for the poll call
     to work at all.)

    And... Visual Studio's debugger is sublime.  I'll jump at the chance
    to fire it up if I think it'll help me debug an issue.  You get much
    better situational awareness than stepping through with gdb.

        Trent.