[Stackless] An idea for making Stackless more naturally usable

Richard Tew richard.m.tew at gmail.com
Tue Sep 5 10:06:01 CEST 2006

On 9/5/06, Andrew Dalke <dalke at dalkescientific.com> wrote:
> According to the notes in asyncore
> # Asynchronous File I/O:
> #
> # After a little research (reading man pages on various unixen, and
> # digging through the linux kernel), I've determined that select()
> # isn't meant for doing asynchronous file i/o.
> # Heartening, though - reading linux/mm/filemap.c shows that linux
> # supports asynchronous read-ahead.  So _MOST_ of the time, the data
> # will be sitting in memory for us already when we go to read it.
> #
> # What other OS's (besides NT) support async file i/o?  [VMS?]
> #
> # Regardless, this is useful for pipes, and stdin/stdout...
> which makes me happy because one of the things I want to stackless-ify
> is subprocess, which uses pipes and hence should work with asyncore.
> Otherwise I think the only solution is an OS thread.  Hmmm, or replace
> open(filename) with
>    some_async_dispatcher(os.popen("cat " + filename))

On the other hand, the best solution I could find for Windows was:


Which is probably a complete replacement for asyncore wrt
both files and sockets.  I'll have a play with it and see if I
can get replacement socket and file objects based on it.  In
the long run, reimplementing its use of IO completion ports
with ctypes, or if possible win32all, might be a better idea
as a fallback if the module is not available.

Pipes however I know nothing about at this time.


Stackless mailing list
Stackless at stackless.com

More information about the Stackless mailing list