[Stackless] The case for Twisted
richard.m.tew at gmail.com
Thu Aug 9 18:16:01 CEST 2007
On 8/9/07, Christopher Armstrong <radix at twistedmatrix.com> wrote:
> I just want to make a quick note, in response to all the discussion of
> asynchronous I/O on this list.
> A lot of people seem to want to write their own event loop for doing
> Stackless I/O. I think this is a waste of time. It's a *lot* of work
> to get a robust and portable event loop.
In a sealed environment where the end result is the only thing which
matters, you are right, it is a waste of time. However, as someone
who works on this sort of thing for Stackless, the end result isn't
what makes the investiture of time and effort feasible. It is the
process of actually doing the work, especially how interesting it is,
a degree of which comes from the education involved.
> Even if you hate the Twisted APIs above the core reactor, it's easy to
> *just* use the Twisted reactor for doing event management and nothing
> else. Let me point out the addReader and addWriter methods on the
> reactor. They're the lowest-level mechanism for getting notifications
> about file descriptors. All you need to do is implement an
> IFileDescriptor with 'fileno', 'doRead', 'doWrite', and
> 'connectionLost' methods, and pass it to those two methods. This
> FileDescriptor object can then do all the necessary stackless
> There are also, of course, many opportunities for integration at a
> higher level, like being able to "block" on Deferreds, or giving a
> stackless API to the Twisted protocol system, and so forth. This is
> great, but I understand some people may not want something so
> high-level. Even if you don't, there's still much to be gained from
> using the low-level reactor implementations.
I think that there is no reason there cannot be multiple solutions.
As many as people are interested enough to write. If the only person
who bothers, writes a Twisted one, then that is what we have. It
sounds like you are giving a lot of valuable information which I hope
someone takes up to do so.
This however, reminds me. If there is an interest in solutions which
provide monkey-patchable socket, file and other objects, then one
thing I would like to see, regardless of the what the solution is
based on, is a common test suite which checks that they behave the
same as the standard non-stackless synchronous Python objects. This
is something which I have been sloppy with, with regard to
stacklesssocket. I haphazardly tested the standard socket object and
based the behaviour on the results of that, and often how I expected
it to work.
Stackless mailing list
Stackless at stackless.com
More information about the Stackless