[Stackless] The case for Twisted

[Tim Kientzle]

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

You'd need some tricks to support cases where a task
can handle any of several different kinds of events.
(maybe a select-like channel wait operation that accepts
a list of channels, waits, and returns the first channel
to have data available?)  Although I admit the examples I
can think of can all be factored into multiple tasklets
each waiting on one channel.

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

Tim Kientzle

_______________________________________________
Stackless mailing list
Stackless at stackless.com
http://stackless.com/cgi-bin/mailman/listinfo/stackless