[Python-ideas] [Python-Dev] PyParallel: alternate async I/O and GIL removal

[Trent Nelson]

On Sat, Nov 16, 2013 at 05:39:13PM -0800, Guido van Rossum wrote:
>    Trent, I watched your video and read your slides. (Does the word
>    "motormouth" mean anything to you? :-)

    Side-effect of both a) not having time to rehearse, and b) trying
    to compress 153 slides into 45 minutes :-)

>    Finally, I'm not sure why you are so confrontational about the way Twisted
>    and Tulip do things. We are doing things the only way they *can* be done
>    without overhauling the entire CPython implementation (which you have
>    proven will take several major release cycles, probably until 4.0). It's
>    fine that you are looking further forward than most of us. I don't think
>    it makes sense that you are blaming the rest of us for writing libraries
>    that can be used today.

    I watched the video today; there's a point where I say something
    along the lines of "that's not how you should do IOCP; they're
    doing it wrong".  That definitely came out wrong -- when limited
    to a single-threaded execution model, which today's Python is, then
    calling GetQueuedCompletionStatus() in a single-threaded event loop
    is really the only option you have.

    (I think I also say "that's just as bad as select()"; I didn't mean
     that either -- it's definitely better than select() when you're
     limited to the single-threaded execution model.  What I was trying
     to convey was that doing it like that wasn't really how IOCP was
     designed to be used -- which is why I dig into the intrinsic link
     between IOCP, async I/O and threading for so many slides.)

    And in hindsight, perhaps I need to put more emphasis on the fact
    that it *is* very experimental work with a long-term view, versus
    Tulip/asyncio, which was intended for *now*.  So although Tulip and
    PyParallel spawned from the same discussions and are attempting to
    attack the same problem -- it's really not fair for me to discredit
    Tulip/Twisted in favor of PyParallel because they're on completely
    different playing fields with vastly different implementation time
    frames (I'm thinking 5+ years before this work lands in a mainstream
    Python release -- if it ever does.  And if not, hey, it can live on
    as another interpreter, just like Stackless et al).

>    Clearly your work isn't ready for python-dev -- it is just too
>    speculative. I've moved python-dev to BCC and added python-ideas.
> 
>    It possibly doesn't even belong on python-ideas -- if you are serious
>    about wanting to change Linux or other *NIX variants, you'll have to go
>    find a venue where people who do forward-looking kernel work hang out.

    Yeah this e-mail was more of a final follow up to e-mails I sent to
    python-ideas last year re: the whole "alternate async approach"
    thread.  (I would have replied to that thread directly, had I kept it
    in my inbox.)



        Trent.