On Nov 15, 6:45 am, roy <[email protected]> wrote: > You mentioned that stackless had certain disadvantages in this thread > (http://www.reddit.com/r/Python/comments/9naln/ > diesel_framework_for_writing_network_applications/).
Stackless is cool in that it gives you the opportunity to have true coroutines without worrying about stack-depth issues. "Truly transparent" concurrency (that doesn't utilize multiple threads or processes) is more approachable with stackless than any other Python- ish method. However, there are a few caveats: Stackless is an entirely separate Python distribution, which makes it difficult to come by in shared hosting situations, harder to find in package management systems, and somewhat awkward to interoperate with the "normal" python installation on the same machine. Quite often (usually?) people are exploring high concurrency apps to write network servers managing many connections. However using the standard socket module and associated protocol libraries (the only pattern stackless supports out of the box) won't work b/c an I/O syscall can block the single OS thread. The workarounds for this involve monkey patching the socket module (http://code.google.com/p/ stacklessexamples/wiki/StacklessNetworking) to involve coordination with a select()-ish async routine under the covers. Due to my own experiences and various secondhand ones around the net, these socket replacements are not without issues. Finally, stackless has, in my testing using some of these socket replacements, been somewhat slower and scaled worse for network apps than a more explicit asynchronous method. Maybe this is because the socket replacement that works best, the asyncore one, doesn't utilize epoll/kqueue/whatever. But I've never successfully gotten the libevent one to work at all. Don't get me wrong, I like stackless and played with it for years (here I am seeking some guidance playing with early versions 8 years ago: http://www.stackless.com/pipermail/stackless/2001-March/000356.html). And people (like CCP games) have been doing Real Work with it for years. I just prefer the tradeoffs made by diesel--speed, standard python, standard socket module, and some nice first class protocol- related patterns at the expense of more explicit yield behavior. > Could you give more details on diesel vs stackless-based approaches? Well, both are sort of "yield control to scheduler", coroutine-esque, so you really could end up with very similar designs if you were to write the same application on both diesel and stackless. The diesel app would have a bit more cruft about generators, whereas stackless could (in theory) just be magically transparent when you issued an I/O call. The diesel stuff has some niceties specialized to network code that would save some boilerplate as opposed to the stackless one, though. But stackless or diesel, you really can't lose--both are very cool approaches to the same general problem space. If you're not using threads and mutexes, it's a win in my book. :-) - Jamie
