I've been "rusting" for a little while and I just convince one of my superiors to use Rust in a kind of mission critical system. The system talk to other equipment through distinct protocols (SNMP, MQTT, MODBUS/TCP and of course SMTP) so that the thing is hard to test. The system was already implemented using NodeRED but I had problems hard to track and decided to replace the critical part by Rust.
I choose the Rust because
- Stability 1: Once it compiles I want it to be as ready as possible
- Stability 2: Statically compiled stuff make it bullet proof against system updates (this is a nice to have for me)
- Small footprint: It's predictable/stable on memory use and light weight
The daemon run on a system with restricted memory but I want it to be concurrent because of a design choice. I have a main task that receives messages through a channel from another tasks and trigger an action if nothing arrives before timeout, or if the value is above some threshold. The values are sensor data, and I may have multiple distinct sources of the same data, if some sensor, or subsystem stop working I still have that data coming from another source. By separating in tasks I can make action triggering agnostic to sensor code.
Now the async stuff... While writing this I found some libraries for this, some libraries for that. It may come the day when I want to use a lib that is sync, but I'm writing async code.
My first idea was to, spawn a new task, an OS thread inside that task, wrap the sync code in that thread, and communicate using async channel, but before going further I decide to come here and see what other people suggests.
PS: My approach feels wrong to me, using thread on async code feels ... wrong ... am I being paranoid?
What are the possible strategies to call sync code from async code without blocking the eventloop?