On Fri, 2020-03-20 at 14:12 +0000, Ian Jackson wrote:
Jürgen Groß writes ("Re: [Xen-devel] [PATCH 1/2] tools/xenstore: Do not abort
xenstore-ls if a node disappears while iterating"):
No, you just don't care for the transaction to succeed or fail (IMO it
should never fail as you are reading only).
So just wrap everything into a transaction.
Yes. xenstored will do the needed buffering.
I think in principle there is a risk here that the transaction might
run for a long time, if the output from xenstore-ls goes to something
that blocks (eg a pager) and can't be written all at once.
But if this is a problem it is a problem afflicting xenstored, not
xenstore-ls.
Ian.
So if I do this...
--- a/tools/xenstore/xenstore_client.c
+++ b/tools/xenstore/xenstore_client.c
@@ -658,7 +658,6 @@ main(int argc, char **argv)
case MODE_write:
transaction = (argc - switch_argv - optind) > 2;
break;
- case MODE_ls:
case MODE_watch:
transaction = 0;
break;
@@ -683,6 +682,7 @@ again:
xth = xs_transaction_start(xsh);
if (xth == XBT_NULL)
errx(1, "couldn't start transaction");
+ printf("started transaction\n");
}
ret = perform(mode, optind, argc - switch_argv, argv + switch_argv, xsh, xth, prefix, tidy, upto, recurse, nr_watches, raw);
... and then repeat my test case as shown in [PATCH 1/1], I should no
longer see...
xenstore-ls:
could not access permissions for 407: No such file or directory
xenstore-ls: in xs_directory (/local/domain/2/foo/407): No such file or
directory
0
But it does still happen. And even if I turn the errx() into a warn()
to stop it aborting, and add a warn() when the xs_transaction_end()
returns EAGAIN... that isn't happening either. I'm just getting
inconsistent data, within a transaction.
