I'm pretty new to async but wanted to give it a spin now that it is
stableized and the crates are getting there. The possibilities are still a bit overwhelming so I'd like some pointers how to structure my app.
Here's it's job:
- core function is to manage selected (e.g., but not limited to, systemd) services
- start, kill & restart
- get current status and log output
- users (managers) connect over the net hosts to call these functions via jsonrpc
- later i'll write a nice webgui for this, not the scope of the app
The app should keep the current state of the system up to date on its own (for systemd I think dbus can notify me).
Now in a non-async-world I would start with the http server, let it create a thread for each client, and have a central thread that takes requests from them (via channels, probably). The central thread then has a loop to answer requests. Then probably another thread per service to handle updating its state in the central data structure.
In the async world I am stuck a bit. The http/jsonrpc part looks easy, just a hyper server which takes care of everything once I
But how to structure the central "thread" that actually runs everything? Is that another task? I need some objects that represent each service, and have methods like
start. But how to call them from the server's rpc handler functions? It seems to me that everything will need to be readonly in
Arc<X> or have a
Mutex which doesn't sound very async?
I'll be glad for any ideas and pointers to existing similar apps in structure... Thanks much!