Jamie, Thanks for your reply. It's well-written and makes a lot of sense.
I feel that what stackless offers so far is a bit low-level. a robust socket package, some higher-level sync mechanism and pre-built protocols are needed. Diesel looks interesting and promising. I will continue playing with it. Thanks again! Roy On Nov 19, 4:36 am, jamwt <[email protected]> wrote: > 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
