Hm, just jumping in out of turn (async ;-) here, but I prototyped pretty clean versions of asyncore.dispatcher and asynchat.async_chat type classes built on top of a promise-based asynchronous I/O socket-monitor. Code ended up looking something like this following:
# Server accepting incoming connections and spawning new HTTP/S channels… this.socket.accept().then(this.handle_connection)
# With a handle_connection() kind of like… def handle_connection(conn): # Create new channel and add to socket map, then… if (this.running()): this.accept().then(this.handle_connection)
# And HTTP/S channels with code like this… this.read_until("\r\n\r\n").then(this.handle_request)
# And handle-request code that did stuff like… if (this.chunked): get_content = this.read_until("\r\n").then(self.parse_chunk_size).then(this.read_bytes) else:. get_content = this.read_bytes(this.content_length) return get_content.then(handle_content)
I'll look around for the code, because it's been well over a year and wasn't complete event then, but that should convey some of how it was shaping up.
Shane Green www.umbrellacode.com 805-452-9666 | email@example.com
On Oct 14, 2012, at 7:07 PM, Glyph firstname.lastname@example.org wrote:
On Oct 13, 2012, at 9:49 PM, Guido van Rossum email@example.com wrote:
It seems that peraps the 'data_received' interface is the most important one to standardize (for the event loop); I can imagine many variations on the handle_read() implementation, and there would be different ones for IOCP, SSL, and probably others. The stdlib should have good ones for the common platforms but it should be designed to allow people who know better to hook up their own implementation.
Hopefully I'll have time to reply to some of the other stuff in this message, but:
Yes, absolutely. This is the most important core issue, for me. There's a little more to it than "data_received" (for example: listening for incoming connections, establishing outgoing connections, and scheduling timed calls) but this was the original motivation for the async PEP: to specify this interface.
Again, I'll have to kick the appropriate people to try to get that started again. (Already started, at https://twitter.com/glyph/status/256983396826378240.) It's on github so anyone can contribute, so if other participants in this thread - especially those of you with connections to the Tornado community - would like to try fleshing some of it out, please go ahead. Even if you just have a question, or an area you think the PEP should address, file an issue (or comment on one already filed).
(Thanks for writing this; this is the kind of insight I am hoping to get from you and others.)
Thanks for the repeated prompts for Twisted representatives to participate.
I was somewhat reluctant to engage with this thread at first, because it looked like a lot of meandering discussion of how to implement stuff that Twisted already deals with quite effectively and I wasn't sure what the point of it all was - why not just go look at Twisted's implementation? But, after writing that message, I'm glad I did, since I realize that many of these insights are not recorded anywhere and in many cases there's no reasonable way to back this information out of Twisted's implementation.
In my (ha ha) copious spare time, I'll try to do some blogging about these topics.
: With one minor nitpick: IOCP and SSL should not be mutually exclusive. This was a problem for Twisted for a while, given the absolutely stupid way that OpenSSL thinks "sockets" work; but, we now have http://twistedmatrix.com/trac/browser/trunk/twisted/protocols/tls.py which could probably be adapted to be framework-neutral if this transport/event-loop level were standardized.
Python-ideas mailing list Pythonfirstname.lastname@example.org http://mail.python.org/mailman/listinfo/python-ideas