Thanks for asking. The Operator framework doesn’t use asyncio for how it handles io and events.
This is primarily because the programming model of charms is a lot of short-lived processes, rather than one long-lived in memory process with lots of asynchronous tasks. (Each event from Juju is actually a separate invocation of your charm script.)
We have talked about designs that would have a longer lived process that exchanges messages with the juju agent. There are two nice properties that we’d like to preserve with any such system:
- You can write relatively linear code which is easier to rationalize about. The actual cpu/data overhead of operators is generally quite low, so you don’t need to pay the mental multiprocessing tax to squeeze out the last performance of the underlying system.
- You know that if the process would die or be restarted, its state is appropriately tracked with persistent storage.
If you do have particular interest or concerns, it would be good to hear from you to make sure we are addressing your use case.