[Stackless] The case for Twisted

Christopher Armstrong radix at twistedmatrix.com
Fri Aug 10 21:44:48 CEST 2007


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
>
> The upper level (scheduler) can then collect the events of all the tasks
> and decide what to do,
> e.g. directly continue a task that is waiting on resources completely
> managed by by stackless
> (e.g. channels) or, if no task can be continued without "asking" the OS
> doing a select/poll/
> whatever and when one of the resources signals "availability" continuing
> that task.

This design looks nice on the surface, but I can't think of any
efficient way to to implement it. Existing mechanisms for asynchronous
I/O on all operating systems only work efficiently if you pass all
event sources to one blocking function; select() and poll() and so
forth need to get all of the file descriptors at once to have any
chance of being efficient. If you had one tasklet per event source
that's responsible for telling the scheduler whether there was data on
that event source, you would have to call select() in each tasklet, or
something, which would ruin performance. There's no way you'd be able
to get ten thousand concurrent connections from that. Is there some
other implementation strategy you had in mind?


-- 
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