[Stackless] An idea for making Stackless more naturally usable
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