Eric Blake <ebl...@redhat.com> writes: > On 11/24/2015 04:37 AM, Fam Zheng wrote: > >>> I think the patch should be dropped, and periodic progress reports >>> should be emitted from within the dump loops that do the heavy lifting. >>> >>> For the ELF format dumps, that loop appears to reside in dump_iterate() >>> [dump.c]. >>> >>> For the compressed format dumps, the loop seems to live in >>> write_dump_pages() [dump.c]. >> >> This is a good idea! >> >> What I'm not sure is where to report the progress. Can it be the monitor >> where >> the dump-guest-memory command was issued? In other words, do we >> support raising >> events before the previous command returns? If yes, can libvirt handle this >> correctly? (But the worst case is using another channel to communicate the >> progress, it is ad-hocery but it must be better than all the risk >> and effort to >> enable multi-threaded dump.) >> >> Eric, Markus, have any idea with the progress reporting? > > I'm fairly certain we support raising events prior to completion of a > synchronous command; what I'm not sure of is whether the event hits the > wire right away or whether it piles up waiting for the next synchronous > command completion. If the latter, then we need to rework it (since the > whole point of this exercise is that we are trying to give progress of a > long-running synchronous command that hasn't completed yet). But we > only have the one monitor connection for libvirt - the only way to pass > events through a second channel is to open a second monitor connection, > but that feels wrong to make libvirt have to track two monitors.
Short answer: events can be sent at any time. Delay can come only from taking the necessary lock, or rate limiting. Longer answer: code triggers an event FOO by calling (QAPI-generated) qapi_event_send_FOO(). This marshalls the event's arguments and calls monitor_qapi_event_queue() (you have to peel off some obfuscating abstraction to see that). Assuming no rate limiting, this simply takes the monitor_lock to call monitor_qapi_event_emit(), which immediately sends the event to all QMP monitors.
