Should there be a ravel.Connection.listen_signal_async?

[helmutg]

Many of the methods have *_async variants, but ravel.Connection.listen_signal does not. It is implemented using dbussy.Connection.bus_add_match which has a bus_add_match_async sibling. That suggests that listen_signal could block. So I'm wondering whether listen_signal is safe to use in an async context. Should there be a listen_signal_async?

Beyond this, I was wondering whether listen_signal could maybe return a context manager that invokes unlisten_signal on __exit__. Would that make sense?

[ldo]

Interesting questions.

First of all, note that at the level of the dbussy module, I don’t keep track of which messages you are watching for. Thus, Connection.bus_add_match_async() doesn’t update any dbussy.Connection state (at least at the Python level), and so doesn’t need to synchronize with any other async method calls. This is different in ravel.Connection, which keeps a table of listeners so it knows where to dispatch incoming messages.

So if there were to be an async version of ravel.Connection.listen_signal(), how would I ensure consistency of state across such a call? Should I lock the Connection object to ensure serialization of calls? At least that would not block the entire event loop like the synchronous call does, but would it still be worth having?

Also, in terms of context managers, my feeling is that the cleanup action should be as simple as possible. But remember that it is actually the D-Bus daemon that keeps track of which messages you are listening for. So in this case the cleanup action would have to communicate with the daemon to remove all those rules, which I feel could be a point of more failures.

A simpler option would be to open a separate private D-Bus connection, and register your listeners on that. Then cleanup consists simply of closing that connection.