search for: guestfs_set_private

...e unitv) */ v = guestfs_int_safe_malloc (g, sizeof *v); *v = gv; - /* XXX This global root is generational, but we cannot rely on every - * user having the OCaml 3.11 version which supports this. - */ - caml_register_global_root (v); + caml_register_generational_global_root (v); guestfs_set_private (g, "_ocaml_g", v); CAMLreturn (gv); @@ -255,10 +252,7 @@ ocaml_guestfs_set_event_callback (value gv, value closure, value events) ocaml_guestfs_raise_error (g, "set_event_callback"); } - /* XXX This global root is generational, but we cannot rely on every - *...

Allow Guestfs.t handle to be garbage collected, and add a regression test.

This is an updated and extended version of the original patch: https://www.redhat.com/archives/libguestfs/2010-August/msg00163.html This adds OCaml and Perl bindings (both tested), support for progress bars in virt-resize, and adds progress notifications to a number of the simpler commands. Still to do is to add progress messages to more commands. There are still a few commands which would be

From: "Richard W.M. Jones" <rjones at redhat.com> --- configure.ac | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/configure.ac b/configure.ac index fa97479..6e42423 100644 --- a/configure.ac +++ b/configure.ac @@ -141,6 +141,10 @@ if test "$gl_gcc_warnings" = yes; then # Work around warning in src/inspect.c. This seems to be a bug in gcc

...imes when + * this might fail such as if the program exits during a + * libguestfs operation. + */ + abort (); + } free (g); } diff --git a/src/private-data.c b/src/private-data.c index 725b74b..d54033b 100644 --- a/src/private-data.c +++ b/src/private-data.c @@ -68,6 +68,8 @@ guestfs_set_private (guestfs_h *g, const char *key, void *data) { struct pda_entry *new_entry, *old_entry, *entry; + ACQUIRE_LOCK (g); + if (g->pda == NULL) { g->pda = hash_initialize (16, NULL, hasher, comparator, freer); if (g->pda == NULL) @@ -85,10 +87,12 @@ guestfs_set_private (guestf...

The existing mechanism was clunky, slow and used ~ 10 MB of local disk. Rich.

Previous discussion here: https://www.redhat.com/archives/libguestfs/2015-June/thread.html#00048 v2: - Use a cleanup handler to release the lock. - Rebase to upstream. Note I have not fixed the problem(s) with error handling (patch 3).

Previously posted in 2015: v1: https://www.redhat.com/archives/libguestfs/2015-June/msg00048.html v2: https://www.redhat.com/archives/libguestfs/2015-June/msg00118.html I have rebased and tidied up the patches, fixing a few spelling mistakes, but they are broadly the same as before. I also ran all the tests, which pass. As with the previous versions, this makes a change to the API, where you

This patch isn't ready to go upstream. In fact, I think we might do a quick 1.30 release soon, and save this patch, and also the extensive changes proposed for the test suite[1], to after 1.30. Currently it is not safe to use the same handle from multiple threads, unless you implement your own mutexes. See: http://libguestfs.org/guestfs.3.html#multiple-handles-and-multiple-threads These

The safe_malloc (etc) functions call g->abort_fn on failure. That's not appropriate for language bindings, and we never intended that these internal functions be used from language bindings, that was just a historical accident. This patch series removes any external use of the safe_* functions. Rich.

Previously posted in 2015: v1: https://www.redhat.com/archives/libguestfs/2015-June/msg00048.html v2: https://www.redhat.com/archives/libguestfs/2015-June/msg00118.html This series was posted about 4 weeks ago: v3: https://www.redhat.com/archives/libguestfs/2017-June/msg00287.html There is no change in this series except I rebased it against current upstream head and retested. Last time there