On 05/24/2017 02:47 PM, Richard W.M. Jones wrote:
On Wed, May 24, 2017 at 12:49:58PM +0200, Michal Privoznik wrote:
> That's quite exact. I mean the word 'guessing'. We can't really
provide
> reliable way of dealing with what you're suggesting (unless we cut the
> limit really small) nor we can guarantee atomicity. Therefore I think it
> would be a waste of time to work on this. Yes, it can be done, but the
> benefits are pretty small IMO.
Why is atomicity a problem?
The atomicity steps in depending on what level we are talking about
serialization. If we do it the way Martin suggested (= on public API
level) then the list of domains may change between two iterations of the
suggested loop. Thus the result obtained would not reflect the reality.
However, if we are talking on RPC level, then there's no atomicity
problem as RPC is 'blind' to the data (it doesn't care what data is sent).
Just structure the libvirtd
messages so that you have:
COLLECT_THE_STATS
- saves the stats into an internal buffer in libvirtd
and returns a handle and a number of stat items
RETURN_THE_STATS
- returns partial subset of previously collected stats,
called multiple times to transfer the data back to libvirt
FREE_THE_STATS
- free the internal buffer
This is exactly what I was proposing in my e-mail that I linked in the
other thread. You just wrote it more cute. Yet again, what's the
gain/advantage of this over one big message?
Michal