Engineering
Studio
By industry · 12
Veodar
Technology · Concurrency in Rust
Tokio is the foundation on which almost everything in Rust that does several things at once is written: handling connections, talking to devices, moving files, waiting for answers. It lets a single program keep thousands of tasks in progress with very few resources. We use it for services that cannot stop and for the background work of desktop apps.
Situations
Tokio pays off when a program spends most of its time waiting, on the network, the disk or a machine, and cannot afford one wait holding up the others.
Dozens or hundreds of sensors, readers or machines that send data whenever they like. Each one is a lightweight task; the slow one does not delay the others.
A slow request blocks the rest, or a connection that does not answer leaves the program waiting forever. Here every wait has its maximum time and its way of being canceled.
Synchronizing, importing a large file or watching a folder while the person keeps working, without the window freezing.
Telemetry, alerts or changes that are sent as they happen, over an open connection, to many clients at once.
Services
Four kinds of job. All four are the same craft: a program doing many things at once without any of them bringing down the others.
Module 1 · TracksPrograms that keep many connections open at once, with devices, with clients or with other systems, and share out the work without one blocking another.
Examples of deliverables
Module 2 · TurntableTasks that run while the application keeps responding: imports, synchronization, folder watching, with their queue, their limit on simultaneous jobs and their progress.
Examples of deliverables
Module 3 · ChannelData that passes from one task to another through channels and goes out as it arrives, with control so the producer does not overwhelm the consumer.
Examples of deliverables
Module 4 · ClockWhat separates a service that holds up from one that has to be restarted: every wait has a limit, every failure its measured retry, and shutdown finishes what is half done.
Examples of deliverables
A working example
Simulated demonstration. Sixteen devices send one reading each; number 7 does not respond. Run the round serving them one by one and then all at once, with and without a maximum wait.
How they are served
Outcome of the round
Choose how to serve them and run the round.
Devices
The devices and their delays are simulated in your browser. What changes between one mode and another is what changes in a real service: who waits for whom, and what happens when someone does not answer.
Integration
Tokio is not seen: it is what sits underneath a service or an app when they do several things at once. Around it are those who talk to it and those it answers.
Where it comes from
Where it goes
How we work and what we deliver
We look at what the service has to handle at once, how long each thing takes and what fails today under load.
We write down the tasks, their limits, what happens when something does not respond and how it shuts down; and what is left out.
The service running with your devices, or with a faithful simulation of them, and its metrics in view.
You test it with real load, unplugging devices and cutting the network halfway.
The map of tasks, the limits chosen and why, and how to read the metrics.
Questions
Missing yours? Write it to info@veodar.com and we'll reply with a specific question, not a brochure.
It is a Rust library, the most widely used for asynchronous programming. It takes care of sharing many tasks among a few processor threads, so that a task that is waiting occupies nobody. Most of the servers, database clients and network libraries in the ecosystem are built on it.
If it does anything more than show forms, almost certainly: synchronizing, talking to a device or importing a file without freezing the window is asynchronous work. In an app built with Tauri, Tokio is already underneath.
The idea is similar: not blocking while you wait. The difference is that Rust uses every processor core, spends less memory and checks at compile time that two tasks do not step on the same data. For a service that moves a lot of data or must always be up, that matters; for a simple integration, Node.js is usually enough.
Whatever was decided, and it is decided beforehand: wait a maximum time, retry a few times with growing pauses, mark it as down and raise an alert. What cannot happen is the whole service sitting there waiting.
That is not its role. Tokio shines when there are many waits; intensive calculation is sent to separate threads so it does not slow the rest. Part of the design consists of separating the two things well.
With metrics and traces from day one: how many tasks are in progress, how long they wait, which ones fail. Without that, a concurrent service is a black box, so it is part of the delivery.
Updated:
Related services
Other technologies
Get started
Knowing how many devices or connections there are and what fails today is enough for a first answer.
What helps us assess it
Before you write, see how we price a project or our solutions by department.
Cookies
We store your language and this choice so the site works. With your permission, we measure visits and speed anonymously, with no tracking cookies or advertising.
Cookies
Necessary
Your language, this choice and spam protection on the contact form.
Anonymous measurement
Page views and load times, in aggregate, through Vercel. No cookies, no tracking across sites.