[Stackless] The case for Twisted

Christopher Armstrong radix at twistedmatrix.com
Fri Aug 10 22:26:49 CEST 2007

On 8/10/07, Tim Kientzle <tim at metaweb.com> wrote:
> On 8/10/07, Joachim König-Baltes <joachim.koenig-baltes at emesgarten.de>
> wrote:
> >> I'd prefer a declarative approach where a task can "inform" an upper level
> >> (typically a scheduler) of the (possibly blocking) events it is waiting on:
> >>
> >> - readability/writeability of a socket/file (OS level resource) or
> >> channel (stackless resource)
> >> - process/thread (OS level) or task (stackless) event such as died,
> >> stopped, ...
> >> - signal
> >> - timers
> In theory, most of these can be converted into channel
> operations by treating the channel as a mechanism for
> tasks to subscribe to certain events.  (E.g., you call
> a method asking to be notified of certain events; that
> method returns a channel endpoint that you can then wait
> on.)

This does look like the right way to do things, and this kind of thing
is easy to do with existing event loops: just have some little layer
that does a channel.send as the callback for events.

> Christopher Armstrong wrote:
> > Existing mechanisms for asynchronous
> > I/O on all operating systems only work efficiently if you pass all
> > event sources to one blocking function...
> Ah, if only that were true.  ;-)  For example,
> select() is generally a poor choice for file operations; much
> better to use aio system calls whose completion
> status has to be polled separately.  But it is true that
> you need a central facility of some sort that can
> map application notification requests onto some set
> of OS facilities (network and timing requests onto
> select(), file requests onto aio calls, etc.).

Sure, some of these central mechanisms are more efficient or usable than others.

Christopher Armstrong
International Man of Twistery
Stackless mailing list
Stackless at stackless.com

More information about the Stackless mailing list