Well, as for the whole confusion-thing, next time you should write "inspired by" instead of "based on" to disambiguate your meaning.
As for threading/non-blocking, it appears that this is a very large subject. Non-blocking IO is a holy-grail of IO-bound applications such as web-servers. However it is not always achievable for all I/O operations on all OS's. For example, you CAM use non-blocking sockets, and basically poll them, but there are other I/O operations that are more problematic, such as the infamous "getaddrinfo()": http://stackoverflow.com/questions/6998309/is-there-a-non-blocking-method-for-host-resolution-in-winapi Here is what Tornado has to offer on that regard: http://www.tornadoweb.org/en/stable/netutil.html?highlight=thread#tornado.netutil.Resolver You'll notice there is no single-threaded-non-blocking option there, but there IS a non-blocking-threaded one: http://www.tornadoweb.org/en/stable/netutil.html?highlight=thread#tornado.netutil.ThreadedResolver As for inter-thread communication, here is another snippet: http://www.tornadoweb.org/en/stable/ioloop.html?highlight=thread Tornado today has many different approaches and target-usages, so it's not a one-size-fits-all - each has it's own trade-offs. For example, you can do sub-processing: http://www.tornadoweb.org/en/stable/process.html?highlight=process#tornado.process.Subprocess But even gevent can't handle some cases, especially in windows - even with the help of gipc: http://gehrcke.de/gipc/#technotes I still think that for the most-part, gevent can handle more cases better, because it relies on a c-extension to circumvent locking issues in ways that pure python (hence tornado's i/o-loop) can not. So although Tornado is being presented as a "single-threaded-non-blocking" web-server, it is still limited in it's extent of non-blocking-I/O in some regards, and features some non-single-process/thread workarounds. So the whole "asynch" story is really irrelevant - it's not the issue of merely substituting threads with co-routines - that by itself does not give you non-blocking capabilities - it is the issue of "how do you make co-routines that can replace threads/processes while still being non-blocking". -- --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
