Re: Standard Asynchronous Python

Discussion in 'Python' started by Dennis Lee Bieber, Sep 10, 2012.

  1. On Sun, 9 Sep 2012 20:07:51 -0400, "Dustin J. Mitchell"
    <> declaimed the following in
    gmane.comp.python.general:

    >
    > My proposal met with near-silence, and I didn't pursue it. Instead, I
    > did what any self-respecting hacker would do - I wrote up a framework,
    > uthreads [4], that implemented my idea. This was initially a simple
    > trampoline scheduler, but I eventually refactored it to run atop
    > Twisted, since that's what I use. To my knowledge, it's never been
    > used.
    >

    So for your small attempt to hide an event-driven dispatcher, one
    has to load a massive event-driven library. Some years ago I tried to
    make sense of Twisted and failed badly. Maybe it makes sense to those
    raised on UNIX style select() (where practically anything that involved
    data transfer over some sort of channel could be tested -- but doesn't
    work as such on Windows where only network sockets can be used, file i/o
    needs to use a different call), but my background is on devices with
    event flag clusters (VMS, and in a way, even AmigaOS -- both of which
    had decent IPC capabilities [mailboxes and message ports,
    respectively]). Closest to event-driven I've coded was using VMS
    Asynchronous System[or Service] Traps -- essentially user mode interrupt
    handlers, which the OS would dispatch when the I/O event completed; no
    need to do a periodic select() and branch -- the main thread would be
    suspended, the specific AST handler would run, and execution would
    return to the point of suspension (I use the term "suspension" but it is
    NOT the same as suspended thread/process -- no new stack is created, the
    AST runs on the suspended code's stack space; it is like a subroutine
    call was jammed in between two instructions)

    Threading, OTOH, has always made sense to me.

    > I'm considering re-drafting the PEP with the following changes:
    >
    > * De-emphasize the thread emulation aspects, and focus on
    > code-portability issues:
    > * callbacks vs. "blocking" calls (e.g., when accepting incoming
    > connections on a socket, how is my code invoked?)
    > * consistent access to primitives, regardless of framework (e.g.,
    > where's the function I call to branch execution?)
    > * nested asynchronous methods
    > * Account for PEP 380 (by making the StopIteration workarounds match
    > PEP 380, and explicitly deprecating them after Python 3.3)
    > * Look forward to a world with software transactional memory [5] by
    > matching that API where appropriate
    >
    > As I get to work on the PEP, I'd like to hear any initial reactions to the idea.
    >


    If I want Modula-2 co-routines, I'll use Modula-2 <G>... Or maybe
    Ada tasks with rendezvous...

    --
    Wulfraed Dennis Lee Bieber AF6VN
    HTTP://wlfraed.home.netcom.com/
     
    Dennis Lee Bieber, Sep 10, 2012
    #1
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. zebulon
    Replies:
    1
    Views:
    654
    Raymond DeCampo
    Jan 24, 2006
  2. Pierre Quentel
    Replies:
    2
    Views:
    332
    John J. Lee
    Jan 10, 2004
  3. Chicken McNuggets

    Asynchronous programming using standard C

    Chicken McNuggets, Sep 2, 2012, in forum: C Programming
    Replies:
    2
    Views:
    427
    Chicken McNuggets
    Sep 3, 2012
  4. Dustin J. Mitchell

    Standard Asynchronous Python

    Dustin J. Mitchell, Sep 10, 2012, in forum: Python
    Replies:
    7
    Views:
    374
    Bryan
    Sep 16, 2012
  5. Oscar Benjamin

    Re: Standard Asynchronous Python

    Oscar Benjamin, Sep 10, 2012, in forum: Python
    Replies:
    0
    Views:
    176
    Oscar Benjamin
    Sep 10, 2012
Loading...

Share This Page