Need a non-blocking API

[marineam]

Perhaps I should have clued into this more when c2243739dbd395c5127ead0eb8296fb70dd217e7 went by but we need the ability to control jobs without waiting for them on all job control methods. This is required for coreos-cloudinit which should never call the blocking API since that can result in deadlocks.

[krnowak]

I was looking at this issue and came up with this: https://github.com/endocode/go-systemd/commit/34e64c5f6e0b4ab491a6c69bdd9fd829568eafb0

This implements async API by using sync API inside goroutines and by using additional channel for return value. I think I must miss something here, because currently I don't see too much point in adding async API, since doing an async call is rather easy to do in Go on client side.

Also, note that I tried doing it the other way around first - implement the async API by using dbus.Object::Go and then implementing sync on top of it, but it was racy, then hacky to avoid the race and a lot more code.

[jonboulle]

@marineam is there something more sophisticated you had in mind?

[blixtra]

@krnowak Do you want to make a pull-request from the commit you pointed to?

[krnowak]

@blixtra nah, I don't think so. This API is pointless IMHO. Unless I'm missing something.

[hamiltont]

FWIW, I found this issue while looking for a non-blocking way to call ListUnits. I'm improving systemd_exporter and about 10% of our total execution time (on each scrape) is waiting for the initial call to ListUnits.

I'm not sure about the internals of go-systemd - perhaps this is completely reasonable (e.g. perhaps dbus takes so long to respond and response processing is so quick that adding concurrency to the response parsing is pointless e.g. it would be effectively equal to "wrap a generator around an API that returns a slice all at once").

If that's not the case, then this is a real-world use case where non-blocking api would be nice to have. ListUnits is one of the serial parts of our application, so w.r.t Amdahl's Law it's always nice to see as few "completely serial" parts as possible :-)

[invidian]

:+1: For closing this issue. See https://dave.cheney.net/practical-go/presentations/qcon-china.html#_leave_concurrency_to_the_caller for reasoning.