Asynchronous networking for jython: the asyncore module
Over the Christmas holidays in 2003, I wrote a design for how Asynchronous Socket I/O might be implemented in jython, using java.nio. I wrote up some notes in HTML, and placed them on a group of pages on xhaus.com. These notes were the basis of the design which I later used to implement asynchronous I/O for jython sockets, which is now a part of the jython distribution.
Although these notes are now out-of-date, having been surpassed by the actual implementation itself, I am publishing them here for historical purposes. The notes are broken down into four main areas.
For documentation on how to use the jython’s asynchronous socket I/O, see the documentation for the socket, select, asyncore, and asynchat modules.
Introduction
The purpose of this document is to discuss the implementation of the cpython asycnore module in jython.
The purpose of the asyncore module is to add the last piece of the puzzle in asynchronous processing: the dispatcher. A dispatcher is responsible for watching multiple registered channels. When a readiness event occurs on any channel, the dispatcher calls special events of a handler object associated with each channel.
Important points to note about the existing cpython asyncore module are as follows.
- It is written pure python.
- It uses only the interface defined by the cpython select module.
- It recreates both the ACCEPT and CONNECT events, even though the cpython select module “hides” these events as POLLIN and POLLOUT events.
There are three main strategies that can be adopted for implementing the asyncore module, along with pros and cons. These are listed in the sections below.
Use the existing cpython asyncore module
The simplest and quickest option for providing asyncore support in jython is to use the existing cpython module. The advantages of this approach include
- No new code need be written
- Existing code is widely used, and thus well tested.
The disadvantages are
- Potential for error because of the possibility of different semantics of ACCEPT and CONNECT events on cpython vs. java (on multiple platforms).
- Mildly inefficient, because of all the mask translation and dictionary lookups
- Existing code is messy because of varying platform support for the select.select() and select.poll() objects in cpython.
Write a jython specific module, using jython
Another approach is write a jython specific asyncore module, written in jython, but directly using the java.nio APIs. There is quite a close correlation between the models in the cpython asyncore module and java.nio.channels.Selector objects. It is possible to write a more efficient asyncore implemenation by using the java APIs directly. The advantanges of this approach are
- Can be more robust because of java’s explicit support for ACCEPT and CONNECT events, which can be directly translated to the relevant “dispatcher” events.
- Can be slightly more efficient, because it avoids a layer of calls to jython implemented poll objects.
- Asyncore model maps directly onto semantics of a java.nio.channels.Selector (even more than cpython)
- “Dispatcher” objects can be registered as attached objects to the java.nio.channels.SelectionKeys that represent them. This would make them directly available to the asyncore.loop() function (which would receive a set of java.nio.channels.SelectionKeys, each having the dispatcher as an attachment, which avoids the dictionary lookups involved in poll objects.
- Can easily be translated to java later on.
The disadvantages are
- New code needs to be written. Not too much though.
- Extensive testing will have to be done to ensure that the new module implements the precise contract of the cpython asyncore module.
TBD: Must write sample code for a jython asyncore module.
Write jython specific module, using java
The last major approach is to, as above, write a jython specific module, but in java. However, this is unlikely to the optimal approach, at least in the short term. Advantages include
- Best possible efficiency
The disadvantages are
- A lot of hard work!
- The java/jython object model is likely to change soon.