Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Re: Standard Asynchronous Python

Reply
Thread Tools

Re: Standard Asynchronous Python

 
 
Dennis Lee Bieber
Guest
Posts: n/a
 
      09-10-2012
On Sun, 9 Sep 2012 20:07:51 -0400, "Dustin J. Mitchell"
<(E-Mail Removed)> 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://www.velocityreviews.com/forums/(E-Mail Removed) HTTP://wlfraed.home.netcom.com/

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Standard Asynchronous Python Dustin J. Mitchell Python 7 09-16-2012 06:45 AM
Re: Standard Asynchronous Python Oscar Benjamin Python 0 09-10-2012 01:40 PM
Asynchronous programming using standard C Chicken McNuggets C Programming 2 09-03-2012 10:43 AM
[J2EE] Standard asynchronous call zebulon Java 1 01-24-2006 09:30 PM
Asynchronous HTTP server in standard library ? Pierre Quentel Python 2 01-10-2004 05:46 PM



Advertisments