I have been playing with tokio already in couple of small projects (ptunnel-rust and indirectly (via hyper) in audioserve), but I cannot say that I’m proficient. Also tokio is very much moving target – what I used couple month ago is already bit outdated now(old version is tokio_core crate – where default executor was on current thread, now it’s work stealing thread pool). So I decided to refresh and deepen my knowledge and created a toy project – stupid jokes server – it’s a TCP sever, which sends a random joke to client after it connects and then closes connection. Jokes are stored in text file, separated by dashed lines. My main interest was to test how to use local file system I/Os, which are blocking by nature, with tokio asynchronous approach (so I initially skipped easiest and probably most efficient implementation, where all jokes would be cached in memory). Usually in a real project you’ll have some blocking code, so I need to know how to handle it. This article is history of my attempts (and failures) recorded in a hope that it might help others in learning tokio (and also writing it down helped me to absorb gained knowledge). Continue reading From Ignorance to Enlightenment – Playing with Tokio
Tag Archives: tokio
Asynchronous Again – Rewriting ptunnel in Rust
Asynchronous programing model is quite popular for I/0 intensive tasks – it enables you effective use of resources, while maintaining agility of and assuring scalability of the application. I myself used asynchronous programming many times – in JavaScript (where it’s omnipresent) , Python ( mainly in asyncio recently, but also bit in twisted, which was one of first network asynchronous libraries I met) and also in OCAML with lwt or Core Async. The concept is always similar for all implementations – I/O operations are returning handles to future results – they are called either Futures, Promises, or Deferred – and they are returned immediately. These futures can have functions attached to them, which are executed later, when I/O result becomes available. Asynchronous programming is very much about functions, it requires first class functions and anonymous functions are very useful here, that’s why asynchronous model flourishes in functional languages. Apart of I/O deferred processing usually there are other utilities for later execution – like timeouts, pausing execution for some time (sleep), tasks synchronization (events, locks). Futures are executed in an “event loop”, a loop that monitors various events from OS (availability of data from I/O), timers, etc. to execute futures (meaning functions attached to them), when appropriate. It’s also very common to chain futures, executing second one with result of first one , when first one is resolved and result is available and the third one with results from the second one and so on. Apart of this basic scheme languages may provide some syntactic sugar around asynchronous model like await and async keywords in Python or C#, which makes it easier to write the code.
Recently, as I’m progressing in learning of Rust, I wondered how asynchronous programing is done in Rust. I decided to remake my old project ptunnel (written in Python) into Rust – ptunnel is a program that tunnels arbitrary connection/protocol through HTTPS proxy, so it can be used to connect IMAP, SMTP or SSH through proxy. In the rest of this article I”l share my experiences from this project. Continue reading Asynchronous Again – Rewriting ptunnel in Rust