summaryrefslogtreecommitdiffstats
path: root/src/guestfs.pod
diff options
context:
space:
mode:
authorRichard W.M. Jones <rjones@redhat.com>2011-04-01 15:50:33 +0100
committerRichard W.M. Jones <rjones@redhat.com>2011-04-01 16:05:45 +0100
commit40f7323134e058c0920caa18c667ea99a4c8b3e8 (patch)
tree01876dc75ebac380ce75855ddfbb5e9b6cd26b88 /src/guestfs.pod
parent6e5f64089631622167e60df25ee009ef83df5170 (diff)
downloadlibguestfs-40f7323134e058c0920caa18c667ea99a4c8b3e8.tar.gz
libguestfs-40f7323134e058c0920caa18c667ea99a4c8b3e8.tar.xz
libguestfs-40f7323134e058c0920caa18c667ea99a4c8b3e8.zip
daemon: Introduce "pulse mode" progress events.
This introduces a new form of progress event, where we don't know how much of the operation has taken place, but we nevertheless want to send back some indication of activity. Some progress bar indicators directly support this, eg. GtkProgressBar where it is known as "pulse mode". A pulse mode progress message is a special backwards-compatible form of the ordinary progress message. No change is required in callers, unless they want to add support for pulse mode. The daemon sends: - zero or more progress messages with position = 0, total = 1 - a single final progress message with position = total = 1 Note that the final progress message may not be sent if the call fails and returns an error. This is consistent with the behaviour of ordinary progress messages. The daemon allows two types of implementation. Either you can just call notify_progress (0, 1); ...; notify_progress (1, 1) as usual. Or you can call the functions pulse_mode_start, pulse_mode_end and/or pulse_mode_cancel (see documentation in daemon/daemon.h). For this second form of call, the guarantee is very weak: it *just* says the daemon is still capable of doing something, and it doesn't imply that if there is a subprocess that it is doing anything. However this does make it very easy to add pulse mode progress messages to all sorts of existing calls that depend on long-running external commands. To do: add a third variant that monitors a subprocess and only sends back progress messages if it's doing something, where "doing something" might indicate it's using CPU time or it's printing output.
Diffstat (limited to 'src/guestfs.pod')
-rw-r--r--src/guestfs.pod14
1 files changed, 14 insertions, 0 deletions
diff --git a/src/guestfs.pod b/src/guestfs.pod
index 91c6b330..eecf96de 100644
--- a/src/guestfs.pod
+++ b/src/guestfs.pod
@@ -1786,6 +1786,20 @@ This is to simplify caller code, so callers can easily set the
progress indicator to "100%" at the end of the operation, without
requiring special code to detect this case.
+=item *
+
+For some calls we are unable to estimate the progress of the call, but
+we can still generate progress messages to indicate activity. This is
+known as "pulse mode", and is directly supported by certain progress
+bar implementations (eg. GtkProgressBar).
+
+For these calls, zero or more progress messages are generated with
+C<position = 0> and C<total = 1>, followed by a final message with
+C<position = total = 1>.
+
+As noted above, if the call fails with an error then the final message
+may not be generated.
+
=back
The callback also receives the procedure number (C<proc_nr>) and