[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
http://radix.twistedmatrix.com/
http://twistedmatrix.com/
http://canonical.com/
_______________________________________________
Stackless mailing list
Stackless at stackless.com
http://stackless.com/cgi-bin/mailman/listinfo/stackless


More information about the Stackless mailing list