Ah, When I left CCP I got permission to take StacklessIO and make it open source. In my last months there, I had been working on a Mac OSX version of it. This would port very easily to linux, with some minor work (mac OSX has a built in thread pool library that linux doesn´t, and threads are necessary for some operations that don't have async versions) Anyway, I was looking through my source for this stuff and couldn't find it, I need to get it from there...
In the end, it is all about how you turn your asynchronous api that the OS provides you with, into a syncronous one for stackless. The approach is different based on the type of API. For windows, the api is completion based. You get a notification when something is done. On linux, it is retry-based, you are invited to invite a non-blocking operation when it is deemed likely to succeed. It turns out that the linux approach is much easier to implement. The windows version was full of all kinds of boilerplate and stuff, mostly because the "outstanding" requests need so much luggage with them while in flight (return buffers, etc). The macos version of stacklessio performed pretty well. I will make this public, but the outline I employed in stacklessio was this: 1) there was a central event queue serviced by the main thread. This was implemented in C and we wold deposit there callbacks that the main thread should run. 2) a socket request would first try to, e.g. recv(). if it got EWOULDBLOCK, it would create a "read request", mark the socket for being watched by someone using select (or equivalent) and then go to sleep, using a channel-receive on the read request. 3) A worker thread would monitor the sockets marked for IO and their associated "request" objects. If the socket is marked as readable, it would then try reading from it. If it succeeded, it would mark that request complete by putting it into the IO event queue, and waking up the main thread if it was sleepeing, waiting for IO. 4) the main thread would wake up, look at the io queue, see a complete request there, call its callback, the callback would call channel-send on the object, and the original stackless reader would wake up. There are a lot of corner cases and details. The whole thing was implemented in C++ to maintain object lifetimes and for other niceties. The important thing for any stackless application, or an IO driven application like this, is that there be only one Event queue, that the main thread services. It has to bee application wide. This is why I was so optimistic about Guido's Tulip proposal, that it would give us an application wide event loop that different frameworks could all use cooperatively. Unfortunately, it turned out to be yet another proprietary socket io mechanism.... K On 27 February 2015 at 16:16, Andrew Francis <[email protected]> wrote: > Hi Folks: > > Pycon 2015 is coming soon. Lately I have been doing work with node.js. I > am not fond of node.js. I have looked at the socket-io protocol. I am > wondering about two things: > > 1) Is there any advice about implementing socket-io? > 2) What does a Stackless Python friend socket-io implementation look like? > I have looked at Go socket-io implementations and they look like Javascript. > > Cheers, > Andrew > > _______________________________________________ > Stackless mailing list > [email protected] > http://www.stackless.com/mailman/listinfo/stackless >
_______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
