<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Tornado on Lorenzo Bolla</title><link>https://lbolla-info.netlify.app/tags/tornado/</link><description>Recent content in Tornado on Lorenzo Bolla</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Thu, 21 Mar 2013 00:00:00 +0000</lastBuildDate><atom:link href="https://lbolla-info.netlify.app/tags/tornado/index.xml" rel="self" type="application/rss+xml"/><item><title>Simple chat with Postgres LISTEN NOTIFY and Tornado IOLoop</title><link>https://lbolla-info.netlify.app/blog/simple-chat-with-postgres-listen-notify-and-tornado-ioloop/</link><pubDate>Thu, 21 Mar 2013 00:00:00 +0000</pubDate><guid>https://lbolla-info.netlify.app/blog/simple-chat-with-postgres-listen-notify-and-tornado-ioloop/</guid><description>&lt;p&gt;Postgres supports from version 8.4 a very interesting functionality: &lt;a href="http://www.postgresql.org/docs/9.2/static/sql-listen.html"&gt;LISTEN&lt;/a&gt;/&lt;a href="http://www.postgresql.org/docs/9.2/static/sql-notify.html"&gt;NOTIFY&lt;/a&gt; allows sending asynchronous messages to clients connected to the database.&lt;/p&gt;
&lt;p&gt;As in a normal &amp;quot;chat&amp;quot;, a client &amp;quot;subscribed&amp;quot; (&lt;code&gt;LISTEN&lt;/code&gt;) to a channel receives all the messages that other clients &amp;quot;sent&amp;quot; (&lt;code&gt;NOTIFY&lt;/code&gt;) on that channel.&lt;/p&gt;
&lt;p&gt;Since version 9.0, a notification message can have a payload string as long as 8000 bytes.&lt;/p&gt;
&lt;p&gt;In order to experiment with this feature, I've implemented a simple chat based on Tornado's &lt;a href="http://www.tornadoweb.org/en/stable/ioloop.html"&gt;IOLoop&lt;/a&gt;. Each client subscribes to a channel (or &amp;quot;room&amp;quot; in chat jargon) and listens to it &lt;a href="http://www.tornadoweb.org/en/stable/ioloop.html#tornado.ioloop.IOLoop.add_handler"&gt;adding a callback&lt;/a&gt; to react to a new notification. In the meantime, in another thread, the client is free to write and submit messages to the &amp;quot;room&amp;quot;. Here is a screenshot of the chat in action:&lt;/p&gt;</description></item><item><title>Blocking tasks in Tornado</title><link>https://lbolla-info.netlify.app/blog/blocking-tasks-in-tornado/</link><pubDate>Tue, 22 Jan 2013 00:00:00 +0000</pubDate><guid>https://lbolla-info.netlify.app/blog/blocking-tasks-in-tornado/</guid><description>&lt;p&gt;Every now and then a &lt;a href="https://groups.google.com/d/topic/python-tornado/NVA5sTFIlPo/discussion"&gt;new discussion is raised on Tornado's mailling list about what is the best way to execute blocking tasks&lt;/a&gt;. It turns out that there are 3 feasible options, in order of increasing complexity:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;em&gt;Optimize blocking calls&lt;/em&gt;. Often, a slow DB query, or an overly complicate template are the blocking bottleneck. Rather than complicating the webserver, the first thing to try is to speed them up. This is sufficient 99% of the time.&lt;/li&gt;
&lt;li&gt;&lt;em&gt;Execute the slow task in a separate thread or process&lt;/em&gt;. This means off-loading the task to a different thread (or process) to the one running the &lt;code&gt;IOLoop&lt;/code&gt;, which is then free to accept other requests.&lt;/li&gt;
&lt;li&gt;&lt;em&gt;Use an asynchronous driver/library to run the task&lt;/em&gt;. For example, something like &lt;a href="http://www.gevent.org/"&gt;gevent&lt;/a&gt;, &lt;a href="http://emptysquare.net/blog/introducing-motor-an-asynchronous-mongodb-driver-for-python-and-tornado/"&gt;motor&lt;/a&gt; and the like.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;This blog post is about the second option, in particular using Python's &lt;a href="https://docs.python.org/3/library/concurrent.futures.html#module-concurrent.futures"&gt;&lt;code&gt;concurrent.futures&lt;/code&gt;&lt;/a&gt; package.&lt;/p&gt;</description></item><item><title>Asynchronous programming with Tornado</title><link>https://lbolla-info.netlify.app/blog/asynchronous-programming-with-tornado/</link><pubDate>Wed, 03 Oct 2012 00:00:00 +0000</pubDate><guid>https://lbolla-info.netlify.app/blog/asynchronous-programming-with-tornado/</guid><description>&lt;p&gt;Asynchronous programming can be tricky for beginners, therefore I think it's useful to iron some basic concepts to avoid common pitfalls. For an explanation about generic asynchronous programming, I recommend you one of the &lt;a href="http://en.wikipedia.org/wiki/Asynchrony"&gt;many&lt;/a&gt; &lt;a href="http://www.cs.brown.edu/courses/cs196-5/f12/handouts/async.pdf"&gt;resources&lt;/a&gt; &lt;a href="http://krondo.com/?page_id=1327"&gt;online&lt;/a&gt;. I will focus solely on asynchronous programming in &lt;a href="http://www.tornadoweb.org/documentation/index.html"&gt;Tornado&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;From Tornado's homepage:&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;FriendFeed's web server is a relatively simple, non-blocking web server written in Python. The FriendFeed application is written using a web framework that looks a bit like web.py or Google's webapp, but with additional tools and optimizations to take advantage of the non-blocking web server and tools. Tornado is an open source version of this web server and some of the tools we use most often at FriendFeed. The framework is distinct from most mainstream web server frameworks (and certainly most Python frameworks) because it is non-blocking and reasonably fast. Because it is non-blocking and uses epoll or kqueue, it can handle thousands of simultaneous standing connections, which means the framework is ideal for real-time web services. We built the web server specifically to handle FriendFeed's real-time features every active user of FriendFeed maintains an open connection to the FriendFeed servers. (For more information on scaling servers to support thousands of clients, see The C10K problem.)&lt;/p&gt;</description></item></channel></rss>