Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #28802

Re: Standard Asynchronous Python

Show all headers | View raw

On Sun, 9 Sep 2012 20:07:51 -0400, "Dustin J. Mitchell"
<dustin@v.igoro.us> 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
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Back to comp.lang.python | Previous | Next | Find similar | Unroll thread

Thread

Re: Standard Asynchronous Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-09-10 01:44 -0400

csiph-web