Synopsis: An overview of Coroutines and Non-blocking I/O/Asynchronous Socket Programming, all related to the C10K problem, focusing on the Python ecosystem, mainly on Linux.
gevent is a coroutine-based Python networking library that uses greenlet to provide a high-level synchronous API on top of the libevent event loop. The “greenlet” package is a spin-off of Stackless, a version of CPython that supports microthreads called “tasklets”. libevent is based on the epoll/Kqueue kernel interface.
The description of Stackless gets to the point:
Stackless Python is an enhanced version of the Python programming language. It allows programmers to reap the benefits of thread-based programming without the performance and complexity problems associated with conventional threads. The microthreads that Stackless adds to Python are a cheap and lightweight convenience which can if used properly, give the following benefits:
+1 for gevent based on numbers from Benchmark of Python WSGI Servers by Nicholas Piël [sitesupport], the maximum comfort by monkeypatching the Python Standard Library as well as other rumors.
Note
copied verbatim from: The Problem with Threads, Edward A. Lee, 2006.
Threads are a seemingly straightforward adaptation of the dominant sequential model of computation to concurrent systems. Languages require little or no syntactic changes to support threads, and operating systems and architectures have evolved to efficiently support them. Many technologists are pushing for increased use of multithreading in software in order to take advantage of the predicted increases in parallelism in computer architectures.
In this paper, I argue that this is not a good idea. Although threads seem to be a small step from sequential computation, in fact, they represent a huge step. They discard the most essential and appealing properties of sequential computation: understandability, predictability, and determinism. Threads, as a model of computation, are wildly nondeterministic, and the job of the programmer becomes one of pruning that nondeterminism. Although many research techniques improve the model by offering more effective pruning, I argue that this is approaching the problem backwards.
Rather than pruning nondeterminism, we should build from essentially deterministic, composable components. Nondeterminism should be explicitly and judiciously introduced where needed, rather than removed where not needed. The consequences of this principle are profound. I argue for the development of concurrent coordination languages based on sound, composable formalisms. I believe that such languages will yield much more reliable, and more concurrent programs.
[...]
“We have argued that threads provide a hopelessly unusable extension of the core abstractions of computation. Yet in practice, many programmers today write multi-threaded programs that work.” ;]
Note
copied verbatim from: Weightless background, Erik J. Groeneveld, 2008.
The problems with call-backs are well-known I suppose. In short, call-backs obfuscate the flow of a program which makes it very hard to write correct code. Also, the code is often hard to maintain and extend. This is the very reason why threads are often used as a alternative: they linearize the code flow again, but also bring their own problems. Call-backs and threads are two different ways to deal with potentially blocking I/O operations, each with their own problems.
Note
copied verbatim from: Coroutines In Python, Sam Rushing, 2000.
A coroutine is a generalization of the subroutine. Forget for a moment everything you’ve been taught about calling functions, and stacks, etc... Think back to BASIC, and the evil GOTO statement. Imagine a more powerful GOTO that could jump back and forth between functions, passing arguments, and you begin to get the idea
Coroutines are a bit of ancient forgotten computer-science lore; stamped out of the collective memory by the hegemony of C. But they are useful in a wide variety of situations that can only be clumsily solved using ‘standard’ tools like threads and processes.
Coroutines can be used to simplify just about any difficult state-machine programming problem. Any time you find yourself tempted to build a complex state machine to solve what should be a simple problem, you’ve actually been pining for coroutines. With them, you can usually turn an ‘inside-out’ problem into a ‘right-side-out’ problem, and replace a few pages of hairy code with a single function.
A popular application of coroutines is in the construction of lightweight threading libraries (in fact, on Win32 coroutines are called ‘fibers‘). Coroutine threads are more scalable than OS threads - a desktop machine can easily juggle tens of thousands of them without gobbling up the entire virtual memory space.
Efficient coroutines hold out the possibility of building powerful, stateful internet servers that are massively scalable.
Note
copied verbatim from: Coroutines, Wikipedia.
Coroutines are useful to implement the following:
Note
copied verbatim from: JavaScript: Iterators and generators, Mozilla Developer Network, 2007.
Generators provide a powerful alternative to custom iterators: they allow you to define an iterative algorithm by writing a single function which can maintain its own state.
A generator is a special type of function that works as a factory for iterators. A function becomes a generator if it contains one or more yield expressions.
Note
copied verbatim from: asyncore, Sam Rushing, 1996.
There are only two ways to have a program on a single processor do “more than one thing at a time.” Multi-threaded programming is the simplest and most popular way to do it, but there is another very different technique, that lets you have nearly all the advantages of multi-threading, without actually using multiple threads. It’s really only practical if your program is largely I/O bound. If your program is processor bound, then preemptive scheduled threads are probably what you really need. Network servers are rarely processor bound, however.
If your operating system supports the select() system call in its I/O library (and nearly all do), then you can use it to juggle multiple communication channels at once; doing other work while your I/O is taking place in the “background.” Although this strategy can seem strange and complex, especially at first, it is in many ways easier to understand and control than multi-threaded programming.
Your asynchronous programming library/framework will bring an event loop, which does the scheduling of the coroutines. See gevent.core, gevent event loop, tornado.ioloop and others.
In the meanwhile, some enhancements since Python 2.5 make generators usable as simple coroutines:
PEP 342 – Coroutines via Enhanced Generators shows at Example 3.:
A simple co-routine scheduler or “trampoline” that lets coroutines “call” other coroutines by yielding the coroutine they wish to invoke.
Note
Be welcome to fill the gaps and correct the mistakes! ;]
| Date | Title | About | Author |
|---|---|---|---|
| 1999 | Continuations and Stackless Python | - or ‘How to change a Paradigm of an existing Program’ ... introduces lightweight, cooperative multitasking aka. coroutines/fibers into Python.` | Christian Tismer |
| 2000 | Stackless Python and Korea | Continuations and Stackless Python - Where Do You Want To Jump Today? | Christian Tismer |
| 2000 | Charming Python: Inside Pythons implementations | Interviews with the creators of Vyper and Stackless Python. | David Mertz |
| 2000 | Coroutines In Python | A coroutine is a generalization of the subroutine. [...] | Sam Rushing |
| 2000 | Introduction to Stackless Python | Stackless Python is an alternative implementation of Python created by independent developer Christian Tismer. He started with the conventional Python language processor managed by the language’s inventor, Guido van Rossum, and patched his own Stackless invention in place of a small but central part of Python’s internals. Stackless Python is the result. This article introduces Tismer’s technology and its significance. In future articles, you’ll be able to read about how to make your own start at programming Stackless Python, as well as the prospects for a merger between Stackless and the main Python distribution. | Cameron Laird |
| 2000 | Programming Stackless Python | You can import continuation_ and do other Stackless Python-based programming yourself with only a bit of effort. This article explains how to get started: where to find the files you’ll need, how to install them, and how to verify that your installation is working properly. | Cameron Laird |
| 2001 | PEP 255 – Simple Generators | This PEP introduces the concept of generators to Python, as well as a new statement used in conjunction with them, the ‘yield’ statement. | Neil Schemenauer, Tim Peters, Magnus Lie Hetland |
| 2001 | Charming Python: Iterators and simple generators | Python 2.2 introduces a new construct accompanied by a new keyword. The construct is generators; the keyword is yield. Generators make possible several new, powerful, and expressive programming idioms, but are also a little bit hard to get one’s mind around at first glance. | David Mertz |
| 2002 | Charming Python: Implementing “weightless threads” with Python generators | The power of microthreads. In a related Charming Python: Iterators and simple generators installment, David introduces a way of simulating full-fledged coroutines with generators and a simple scheduler. It is possible to extend this scheduler in straightforward ways to allow extremely lightweight threading of multiple processes. Much as with Stackless Python microthreads, pseudo-coroutine ‘weightless threads‘ require almost none of the context switch and memory overhead of OS – or even userland – threads. Here David introduces weightless threads as an elegant solution for problems whose natural solutions involve large numbers of cooperating processes. | David Mertz |
| 2005 | PEP 342 – Coroutines via Enhanced Generators | This PEP proposes some enhancements to the API and syntax of generators, to make them usable as simple coroutines. It is basically a combination of ideas from the PEPs PEP 288 – Generators Attributes and Exceptions (Raymond Hettinger) and PEP 325 – Resource-Release Support for Generators (Samuele Pedroni), which may be considered redundant if this PEP is accepted. | Guido van Rossum, Phillip J. Eby |
| 2005 | Unsung Heroes of Python: asynchat/asyncore | Tim Lesher | |
| 2007 | PEP: XXX - Standard Microthreading Pattern | See uthreads, a microthreading library layered on top of Twisted, esp. StandardMicrothreadingPattern - Description of a proposed standard microthreading programming pattern | Dustin J. Mitchell |
| 2009 | PEP 380 – Syntax for Delegating to a Subgenerator | A syntax is proposed for a generator to delegate part of its operations to another generator. This allows a section of code containing ‘yield’ to be factored out and placed in another generator. Additionally, the subgenerator is allowed to return with a value, and the value is made available to the delegating generator. | Gregory Ewing |
| 2009 | PEP: XXX - Cofunctions | A syntax is proposed for defining and calling a special type of generator called a ‘cofunction’. It is designed to provide a streamlined way of writing generator-based coroutines, and allow the early detection of certain kinds of error that are easily made when writing such code, which otherwise tend to cause hard-to-diagnose symptoms. | Gregory Ewing |
| 2009 | Asynchronous Servers in Python | A look at a selection of asynchronous servers implemented in Python together with a Ping Pong benchmark, which measures the raw socket performance. | Nicholas Piël [sitesupport] |
| 2009 | Experimental HTTP server using Stackless Python | This blog post documents my experiment to write a non-blocking HTTP server based on coroutines (tasklets) of Stackless Python. My goal was to write a minimalistic web server server which can handle cuncurrent requests by using non-blocking system calls, multiplexing with select(2) or epoll_(2), returning a simple ‘Hello, World’ page for each request, using the coroutines of Stackless Python. I’ve done this, and measured its speed using ApacheBench, and compared it to the ‘Hello, World’ server of Node.js. Note: This eventually became Syncless. | Péter Szabó |
| 2010 | Feature comparison of Python non-blocking I/O libraries | This blog post is a tabular feature comparison of Syncless and the 6 most popular event-driven and coroutine-based non-blocking (asynchronous) networking I/O libraries for Python. It was inspired by Asynchronous Servers in Python (published on 2009-11-22), which compares the features and the performance of 14 Python non-blocking networking I/O libraries. We’re not comparing generator-based (yield) solutions here. We haven’t made performance measurements, so speed-related claims in this comparison are beliefs and opinions rather than well-founded facts. | Péter Szabó |
| 2010 | Benchmark of Python WSGI Servers | A look at how different WSGI servers perform at the handling of a full HTTP request. | Nicholas Piël [sitesupport] |
| 2011 | Emulating Stackless and greenlet with each other [EuroPython2011] | Stackless Python and the greenlet package for CPython are two different implementations of coroutine support for Python. (Coroutines are fundamental building blocks of I/O frameworks like gevent, Eventlet, Concurrence and Syncless to conveniently handle thousands of socket connections at a time without creating threads.) Stackless and greenlet implement a different interface. However, each is powerful enough so that it can be used to emulate the other one. In this talk we explore the differences and discuss design decisions and testing strategies of the emulations we have implemented. | Péter Szabó |
| 2011 | Beyond Python Enhanced Generators [EuroPython2011] | Right after the introduction of PEP342 (Enhanced Generators) we started to decompose programs into generators. It was soon discovered that for real-life problems one would need something like ‘yield from’, as is described in PEP380. At that time, we already had a similar solution called ‘compose’, which we adapted to PEP380. (http://weightless.io/compose) After 5 years working with ‘compose’, we found a small set of other features that are essential if you want to use Enhanced Generators not only as a way of lightweight command scheduling, but also a a pipe-line, or parser. Indeed, the latter concepts are what real co-routines are about. This talk introduces what is needed on top of PEPs 342 and 380 based on experience with decomposing big enterprise search engines into co-routines. Parts of it have been presented on SPA (2008) and EuroPython (2010). Understanding of Enhanced Generators is a prerequisite. |
Erik J. Groeneveld |
| Date | Title | About | Author |
|---|---|---|---|
| 1996 | asyncore | asyncore — Asynchronous socket handler. Basic infrastructure for asynchronous socket service clients and servers. | Sam Rushing |
| 1999 | Medusa | Medusa is an architecture for very-high-performance TCP/IP servers (like HTTP, FTP, and NNTP). Medusa is different from most other servers because it runs as a single process, multiplexing I/O with its various client and server connections within a single process/thread. | Sam Rushing, Andrew Kuchling |
| 1999 | The Stackless approach » Continuations and Stackless Python - or ‘How to change a Paradigm of an existing Program’ « introduces lightweight, cooperative multitasking aka. coroutines/fibers into Python. (since Python 1.5.2)` | Christian Tismer | |
| 2001 | Twisted | An event-driven networking engine, around for years, a large framework. It uses deferreds (an abstraction over callback parameters) aka. futures. The programming model is mostly callback-based, but there is Twisted DeferredGenerator. | Glyph Lefkowitz |
| 2005 | peak.events | Provides an event-driven programming framework that supports ultralight microthreads implemented via generators. It can stand alone or can be used atop Twisted for a more intuitive approach to asynchronous programming. Can write event-driven code in a more natural, sequential, untwisted style, but without giving up access to Twisted ‘s many great features. | PEAK Community |
| 2006 | Eventlet | A concurrent networking library. Combines epoll/Kqueue with coroutines. 2007 open sourced by Linden Labs. Programming model: lightweight threads, making your code feel synchronous. | Bob Ippolito |
| 2006 | Kamaelia | Kamaelia is a Python library by BBC Research for concurrent programming using a simple pattern of components that send and receive data from each other. This speeds development, massively aids maintenance and also means you build naturally concurrent software. | |
| 2007 | peak.events.trellis | Event-Driven Programming The Easy Way. What Trellis is for is relatively easy to explain: it’s for safely and transparently updating things in response to changes. An event-driven system that truly doesn’t suck, it’s like a spreadsheet for code. Read more: [1] | Phillip J. Eby |
| 2007 | Chiral | Chiral is a lightweight coroutine-based networking framework for high-performance internet and Web services. Coroutines in Chiral are based on Python 2.5’s generators, as specified in PEP 342. The Coroutine class wraps around a generator and handles scheduling. | Jacob Potter |
| 2007 | Tornado | Scalable, non-blocking web server. Proven on-site technology. Tornado’s I/O-loop (tornado.ioloop) is based on epoll/Kqueue. 2009 open sourced by Facebook. Programming model: callback-based. See also: The technology behind Tornado, FriendFeed’s web server, Tornado: Facebook’s Real-Time Web Framework - With Paul Buchheit. | Bret Taylor, Paul Buchheit [FriendFeed] |
| 2008 | circuits | Lightweight Event driven and Asynchronous Application Framework for the Python Programming Language with a strong Component Architecture. | James Mills |
| 2008 | Weightless |
In use at Meresco. See also: Weightless background |
Erik J. Groeneveld |
| 2008 | cogen | Crossplatform asynchronous network oriented python framework based on python 2.5 enhanced generators. cogen is a crossplatform library for network oriented, coroutine based programming using the enhanced generators from python 2.5. The project aims to provide a simple straightforward programming model similar to threads but without all the problems and costs. cogen’s goal is to enable writing code in a seemingly synchronous and easy manner in the form of generators that yield calls and receive the result from that yield. These calls translate to asynchronous and fast os calls in cogen’s internals. Includes an enhanced WSGI server. See also: cogen and greenlets | Maries Ionel Cristian |
| 2009 | python-multitask | Cooperative multitasking and asynchronous I/O using Python generators. python-multitask allows Python programs to use generators (a.k.a. coroutines) to perform cooperative multitasking and asynchronous I/O. Applications written using multitask consist of a set of cooperating tasks that yield to a shared task manager whenever they perform a (potentially) blocking operation, such as I/O on a socket or getting data from a queue. The task manager (scheduler) temporarily suspends the task (allowing other tasks to run in the meantime) and then restarts it when the blocking operation is complete. Such an approach is suitable for applications that would otherwise have to use select() and/or multiple threads to achieve concurrency. | Christopher Stawarz |
| 2009 | gevent | Combines libevent with coroutines (gevent.core, gevent event loop), but does it right. See Comparing gevent to eventlet. Programming model: lightweight threads, making your code feel synchronous. | Denis Bilenko [sitesupport] |
| 2009 | Concurrence | Concurrence is a framework for creating massively concurrent network applications in Python. It takes a Lightweight-tasks-with-message-passing approach to concurrency. The goal of Concurrence is to provide an easier programming model for writing high performance network applications than existing solutions (Multi-threading, Twisted, asyncore etc). Concurrence uses Lightweight tasks in combination with libevent to expose a high-level synchronous API to low-level asynchronous IO. Fast low-level IO buffers implemented in Pyrex_. DBAPI 2.0 compatible MySQL driver implementation (native & asynchronous, with optimized protocol support written in Pyrex_). Upcoming: Improved Memcache support (Ketama hashing, Connection Management). | Henk Punt |
| 2009 | Syncless | Syncless is a non-blocking (asynchronous) concurrent client and server socket network communication library for Stackless Python 2.6 (and also for regular Python with greenlet). For high speed, Syncless uses libev (and libevent) for event notification, and parts of Syncless ‘ code is implemented in Pyrex_/Cython_ and C_. This alone makes Syncless faster than many other non-blocking network libraries for Python. Syncless contains an asynchronous DNS resolver (using evdns) and a HTTP server capable of serving WSGI_ applications. Syncless aims to be a coroutine-based alternative of event-driven networking engines (such as Twisted, asyncore, pyevent_, python-libevent_ and FriendFeed’s Tornado), and it’s a competitor of gevent, Eventlet and Concurrence. See also: Experimental HTTP server using Stackless Python | Péter Szabó |
| 2010 | monocle | monocle - An async programming framework with a blocking look-alike syntax. monocle straightens out event-driven code using Python’s generators. It aims to be portable between event-driven I/O frameworks, and currently supports Twisted and Tornado. It’s for Python 2.5 and up. | Greg Hazel and Steven Hazel. |
| Date | Title | About | Author |
|---|---|---|---|
| 1977 | Icon | Icon generators are a key concept in Icon. Generators drive much of the loop functionality in the language, but do so more directly; the programmer does not write a loop and then pull out and compare values, Icon will do all of this for you. | |
| 1993 | ACE | The ADAPTIVE Communication Environment (ACE) is a freely available, open-source object-oriented (OO) framework that implements many core patterns for concurrent communication software. Esp. see: ACE Reactor: event demultiplexing and event handler dispatching | |
| 1996 | POE: Perl Object Environment | POE is a Perl framework for reactive systems, cooperative multitasking, and network applications. It supports 10 different event loops. See also: POE Whitepaper | Rocco Caputo |
| 1998 | JAWS | The JAWS Adaptive Web Server - An Application Framework for High Performance Web Systems. Based on ACE. | |
| 1999 | The C10K problem | Interesting scalable server implementations | Dan Kegel |
| 2001 | `epoll - I/O event notification facility`_ | TODO | Davide Libenzi |
| 2001 | Coroutines for Ruby | Coroutines allow blocks to run concurrently while you control when the context is switched between them. | Marc De Scheemaecker |
| 2002 | Linux File AIO | Kernel Asynchronous I/O (AIO) Support for Linux. AIO enables even a single application thread to overlap I/O operations with other processing, by providing an interface for submitting one or more I/O requests in one system call (io_submit()) without waiting for completion, and a separate interface (io_getevents()) to reap completed I/O operations associated with a given completion group. The AIO implementation presented here should have similar performance characteristics to the event interface that /dev/epoll uses, as both models have a 1-1 correlation between events being generated and the potential for progress to be made. One area where AIO poll differs significantly from /dev/epoll stems from readiness vs ready state notification: an async poll is like poll in that the operation completes when the descriptor has one of the specified events pending. However, /dev/epoll only generates an event when the state of the monitored events changes. See also: An AIO Implementation and its Behaviour and Linux Asynchronous I/O Design |
Benjamin C. R. LaHaise` |
| 2002 | nginx | Nginx is a free, open-source, high-performance HTTP server and reverse proxy, as well as an IMAP/POP3 proxy server. Nginx is known for its high performance, stability, rich feature set, simple configuration, and low resource consumption. Nginx is one of a handful of servers written to address the C10K problem. Unlike traditional servers, Nginx doesn’t rely on threads to handle requests. Instead it uses a much more scalable event-driven (asynchronous) architecture. This architecture uses small, but more importantly, predictable amounts of memory under load. Even if you don’t expect to handle thousands of simultaneous requests, you can still benefit from Nginx’s high-performance and small memory footprint. Nginx scales in all directions: from the smallest VPS all the way up to clusters of servers.
See also: nginx: Architecture and scalability |
Igor Sysoev |
| 2003 | Java NIO: New I/O APIs | The new I/O (NIO) APIs introduced in Java v1.4 provide new features and improved performance in the areas of buffer management, scalable network and file I/O, character-set support, and regular-expression matching. Esp. A multiplexed, non-blocking I/O facility for writing scalable servers. | Sun Microsystems |
| 2004 | Apache Event MPM | Event-based multi-processing module for the Apache HTTP Server based on epoll/Kqueue. | |
| 2004 | Apache MINA | A Multi-purpose Infrastructure for Network Applications. A network application framework which helps users develop high performance and high scalability network applications easily. It provides an abstract event-driven asynchronous API over various transports such as TCP/IP and UDP/IP via Java NIO. See also: Introduction to MINA. | Trustin Lee |
| 2005 | Jetty | Jetty 6 brings Jetty: Asynchronous Servlets and Continuations | |
| 2006 | Java 6: Enhancements in Java I/O | A new java.nio.channels.SelectorProvider implementation that is based on the Linux epoll event notification facility is included. The epoll facility is available in the Linux 2.6, and newer, kernels. The new epoll-based SelectorProvider implementation is more scalable than the traditional poll-based SelectorProvider implementation when there are thousands of SelectableChannels registered with a Selector. The new SelectorProvider implementation will be used by default when the 2.6 kernel is detected. The poll-based SelectorProvider will be used when a pre-2.6 kernel is detected. See also: To poll or epoll: that is the question. | Sun Microsystems |
| 2006 | Boost.Coroutine | The Boost.Coroutine library contains a family of class templates that wrap function objects in coroutines. Coroutines are a generalization of subroutines that can return and be reentered more than once without causing the destruction of automatic objects. Coroutines are useful whenever it is necessary to keep state across a function call, a job usually reserved to stateful function objects. | Giovanni P. Deretta |
| 2007 | JSR 315: Java™ Servlet 3.0 Specification | One of the significant enhancements made in ‘JSR 315: Java Servlet 3.0’, is support for asynchronous processing, see Asynchronous Support in Servlet 3.0. | |
| 2007 | Grizzly | Writing scalable server applications in the Java™ programming language has always been difficult. Before the advent of the Java New I/O API (NIO), thread management issues made it impossible for a server to scale to thousands of users. The Grizzly NIO and Web framework has been designed to help developers to take advantage of the Java™ NIO API. Grizzly’s goal is to help developers to build scalable and robust servers using NIO and we are also offering extended framework components: Web Framework (HTTP/S), Bayeux Protocol, Servlet, HttpService OSGi and Comet. | Jeanfrancois Arcand |
| 2007 | JavaScript: Iterators and generators | Iterators and Generators, introduced in JavaScript 1.7, bring the concept of iteration directly into the core language. While custom iterators are a useful tool, their creation requires careful programming due to the need to explicitly maintain their internal state. Generators provide a powerful alternative: they allow you to define an iterative algorithm by writing a single function which can maintain its own state. A generator is a special type of function that works as a factory for iterators. A function becomes a generator if it contains one or more yield expressions. | |
| 2008 | Atmosphere | Atmosphere is a POJO based framework using Inversion of Control (IoC) to bring push/Comet and Websocket to the masses! The Atmosphere Framework is designed to make it easier to build asynchronous/Comet‐based Web applications that include a mix of Comet and RESTful behavior. The Atmosphere Framework is portable and can be deployed on any Web Server that supports the Servlet Specification 2.3. | Jeanfrancois Arcand |
| 2008 | Netty | The Netty project is an effort to provide an asynchronous event-driven network application framework and tools for rapid development of maintainable high performance & high scalability protocol servers & clients. | Trustin Lee, JBoss Inc. |
| 2009 | Reflex | Reflex is a class library for writing reactive Perl programs. It provides base classes for reactive objects, and specific subclasses for various tasks. | Rocco Caputo |
| 2009 | Node.js | Evented I/O for V8 JavaScript. Node.js is a server-side JavaScript environment that uses an asynchronous event-driven model. This allows Node.js to get excellent performance based on the architectures of many Internet applications. | Ryan Dahl, Isaac Schlueter |
| 2010 | Gretty | Gretty is simple framework for networking, both building web servers and clients. Built on top of netty, it supports NIO style http server, asynchronous http client. It also supports both websocket server and client. See also: 512000 concurrent websockets with Groovy++ and Gretty. | Alex Tkachman |
| 2010 | async-http-client | Asynchronous Http Client library for Java. The library uses Java non blocking I/O for supporting asynchronous operations. The default asynchronous provider is build on top of Netty, the Java NIO Client Server Socket Framework from JBoss, but the library exposes a configurable provider SPI which allows to easily plug in other frameworks. | Jeanfrancois Arcand, Ning Inc. |
Greenlets (used by gevent) are provided as a C extension module for the regular unmodified interpreter, while Stackless is a patch into the regular Python. On the other hand, Stackless could improve efficiency by about 10% by using soft switching instead of hard switching (this statement was made by Christian Tismer, the inventor of Stackless).
The upcoming gevent 1.0 will be based on libev, see libev and libevent.
On EuroPython2011 it was announced by some authors of PyPy, that Tasklets and Greenlets support for PyPy would require some weeks of effort.
| [1] | A cross between peak.events and PyCells, but built on Contextual and still able to work with – or without – Twisted. Inspired by the Cells library for Common Lisp. Solves the callback-style problems by introducing automatic callback management. Instead of worrying about subscribing or “listening” to events and managing the order of callbacks, you just write rules to compute values. The Trellis “sees” what values your rules access, and thus knows what rules may need to be rerun when something changes – not unlike the operation of a spreadsheet. The ‘Trellis’ name comes from Dr. David Gelernter’s 1991 book, “Mirror Worlds”, where he describes a parallel programming architecture he called “The Trellis”. |