search for: full_major

On Thu, Oct 15, 2015 at 10:07:45AM +0100, Richard W.M. Jones wrote: > On Wed, Oct 14, 2015 at 07:55:41PM +0300, Roman Kagan wrote: > > Libguestfs supports passing an ISO image as a source of virtio windows > > drivers to v2v. > > > > This series attempts to make it simpler and better scoped. > > Looks good (apart from patch 3 - the Gc.compact is necessary!) Why?

...xplicit GC (which was > introduced at the time exactly to clear up that handle in commit > 47b5f245bec908f803f0a89c3b1e3166cfe33aad)? Just because the handle becomes unreachable doesn't mean the GC will immediately collect it. Objects are only required to be finalized when you invoke Gc.full_major (Gc.compact calls Gc.full_major). Previous to these patches, the handle was still unreachable, but Gc.compact didn't free it because of a different problem. That different issue has been fixed by: https://github.com/libguestfs/libguestfs/commit/8bbc5e73cb5b56b5cfbe979ac0e1c14d1701a0d8 In su...

...icit_close.ml b/ocaml/t/guestfs_065_implicit_close.ml index 567e550b4..5e00c21ac 100644 --- a/ocaml/t/guestfs_065_implicit_close.ml +++ b/ocaml/t/guestfs_065_implicit_close.ml @@ -30,8 +30,8 @@ let () = *) (* This should cause the GC to close the handle. *) -let () = Gc.compact () +let () = Gc.full_major () let () = assert (!close_invoked = 1) -let () = Gc.compact () +let () = Gc.full_major () -- 2.40.1

...caml/t/guestfs_065_implicit_close.ml index f2dfecbd5c..04e511dd8a 100644 --- a/ocaml/t/guestfs_065_implicit_close.ml +++ b/ocaml/t/guestfs_065_implicit_close.ml @@ -16,6 +16,14 @@ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. *) +let () = + (* In OCaml 5, Gc.full_major does not actually collect the handle + * for unknown reasons. Skip the test until we can resolve this. + * https://discuss.ocaml.org/t/ocaml-5-forcing-objects-to-be-collected-and-finalized/12492/2 + *) + if Sys.ocaml_version >= "5" then + exit 77 + let close_invoked = ref 0...

...ex f2dfecbd5c..04e511dd8a 100644 > --- a/ocaml/t/guestfs_065_implicit_close.ml > +++ b/ocaml/t/guestfs_065_implicit_close.ml > @@ -16,6 +16,14 @@ > * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. > *) > > +let () = > + (* In OCaml 5, Gc.full_major does not actually collect the handle > + * for unknown reasons. Skip the test until we can resolve this. > + * https://discuss.ocaml.org/t/ocaml-5-forcing-objects-to-be-collected-and-finalized/12492/2 > + *) > + if Sys.ocaml_version >= "5" then > + exit 77 &gt...

...; introduced at the time exactly to clear up that handle in commit > > 47b5f245bec908f803f0a89c3b1e3166cfe33aad)? > > Just because the handle becomes unreachable doesn't mean the GC will > immediately collect it. Objects are only required to be finalized > when you invoke Gc.full_major (Gc.compact calls Gc.full_major). > > Previous to these patches, the handle was still unreachable, but > Gc.compact didn't free it because of a different problem. That > different issue has been fixed by: > > https://github.com/libguestfs/libguestfs/commit/8bbc5e73cb5b56b5c...

No action required here as I have pushed this already, this is just for your information. Rich.

In version 2: - No substantial change, I just tidied up the code a bit. - Removed one case where whitespace changes had crept in. Rich.

...Caml-level representation of objects like xpathobj so they contain a reference back to the higher-level objects (xpathctx & doc). Therefore holding an xpathobj means that the doc cannot be freed. However that alone is not quite sufficient. There is a further problem when the program calls Gc.full_major, Gc.compact etc., or even just when xpathctx & doc happen to be freed at the same time. The GC won't necessarily free them in the right order as it knows both need to be freed but doesn't know that one must be freed before the other. To solve this we have to move the finalisers into O...

...Caml-level representation of objects like xpathobj so they contain a reference back to the higher-level objects (xpathctx & doc). Therefore holding an xpathobj means that the doc cannot be freed. However that alone is not quite sufficient. There is a further problem when the program calls Gc.full_major, Gc.compact etc., or even just when xpathctx & doc happen to be freed at the same time. The GC won't necessarily free them in the right order as it knows both need to be freed but doesn't know that one must be freed before the other. To solve this we have to move the finalisers into O...