[Stackless] Asyncronous IO (Was: Re: question about stackless)
psheer at icon.co.za
Tue Jun 11 23:18:39 CEST 2002
On 2002.06.11 17:18 Christian Tismer wrote:
> psheer at icon.co.za wrote:
> > Hi there
> > (if there is a more appropriate forum to ask this question, please
> > direct me to it.)
> Would be intersting to discuss on stackless at tismer.com
> > I would like to know what happens in stackless if a
> > tasklet is waiting on a file descriptor for reading -
> > such as waiting on a socket for data?
> > will the other taskless continue to run? or will all
> > tasklets lock up?
> At the moment, they will all lock up.
> But I'm planning to write a general mechanism
> that is able to do async I/O, so that tasklets
> which are waiting for I/O are blocked, but others
> not. I'm thinking of FreeBSD kqueue, for instance.
I think the proper way to do this is to add to an
fd_set all tasklets pending for reading or writing.
The main interpretor loop should then select() on
these fd_set's and complete the respective read()s and
write()s. This is extremely portable and efficient.
The reason I ask this question is because I believe
this is how all interpretors should work. It obviates
having to write a state machine in C around a select loop
the way many programs do in order to implement concurrent
IO. Some programs that work this way are the X server, BSD's
pppd, dnscache, dnrd, rfd (my own), Gtk, etc.
If I cannot find an interpretor that works in this way,
I'll be forced to write one myself. But python would
be preferable of course.
The benefits of such an implementation is that a python
program could handle multiple concurrent ftp, httpd, mail
irc, (etc.) connections efficiently and within a single
thread, using multiple tasklets.
Paul Sheer Consulting IT Services . . . Tel . . . +27 21 761 7224
Email . . . psheer at icon.co.za . . . . . . Pager . . . 088 0057245
Linux development, cryptography, recruitment, support, training
http://www.icon.co.za/~psheer . . . . http://rute.sourceforge.net
L I N U X . . . . . . . . . . . . The Choice of a GNU Generation
Stackless mailing list
Stackless at www.tismer.com
More information about the Stackless