Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Raise errors in gc worker #2065

Merged
merged 1 commit into from Sep 2, 2022
Merged

Conversation

icristescu
Copy link
Contributor

From #2039: the gc worker routine raises errors instead of propagating a result. The errors are catched at the end and converted it in a result for write_gc_output.

@codecov-commenter
Copy link

codecov-commenter commented Sep 1, 2022

Codecov Report

Merging #2065 (b61da8b) into main (5374885) will increase coverage by 0.03%.
The diff coverage is 43.41%.

@@            Coverage Diff             @@
##             main    #2065      +/-   ##
==========================================
+ Coverage   64.34%   64.38%   +0.03%     
==========================================
  Files         131      132       +1     
  Lines       15584    15570      -14     
==========================================
- Hits        10028    10024       -4     
+ Misses       5556     5546      -10     
Impacted Files Coverage Δ
src/irmin-pack/unix/errors.ml 26.66% <0.00%> (-3.34%) ⬇️
src/irmin-pack/unix/gc.ml 40.09% <38.88%> (+31.49%) ⬆️
src/irmin-pack/unix/ext.ml 61.15% <70.00%> (-5.51%) ⬇️
src/irmin-pack/unix/file_manager.ml 83.90% <100.00%> (+1.23%) ⬆️
src/irmin-pack/unix/gc_intf.ml 100.00% <100.00%> (ø)
src/irmin-pack/unix/mapping_file.ml 92.80% <100.00%> (+0.10%) ⬆️
src/irmin-fs/unix/irmin_fs_unix.ml 68.38% <0.00%> (+0.64%) ⬆️
src/irmin-fs/irmin_fs.ml 82.42% <0.00%> (+1.21%) ⬆️
... and 1 more

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

Copy link
Member

@metanivek metanivek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good overall. I think the code will be nicer in this area without the result monad.

Errors.finalise (fun _outcome ->
Ao.close prefix |> Errs.log_if_error "GC: Close prefix")
Ao.close_exn prefix ~log_if_error:"GC: Close prefix")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the callback for Errors.finalise has type 'a -> unit (and so the result monad doesn't really leave this scope), I'd say it is okay to leave as it is currently. And then you don't need Ao.close_exn.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes agree, thanks!

in
Ok ()
Errors.finalise (fun _outcome : unit ->
Io.fsync_and_close prefix
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment here which means no need for (Io|Ao).fsync_and_close.

module Ao = struct
include Append_only_file.Make (Fm.Io)

let create_rw_exn ~path ~auto_flush_callback =
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thoughts on moving to Append_only_file? With other changes mentioned this would remove the need for this Ao extension.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm tempted to leave it here. My understanding is that we don't want to propose a create_exn for other uses that in this part of the code. (as a minor plus, having it here, we can provide the defaults for overwrite and auto_flush_threshold).

Agree that this module wrapping is a bit ugly, so I can remove it and unwrap the function when used, if you prefer.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

create_rw_exn would be the only exception-based function in Append_only_file that exists for convenience reasons. The others exist for performance reasons.

My taste would be to leave create_rw_exn here, but that's only my taste

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Those are all good reasons to keep it here. 👍

let open Result_syntax in
fsync x >>= (fun () -> close x) |> Errs.log_if_error log_if_error

let open_exn ~path ~readonly =
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thoughts on moving to Io? With other changes mentioned this would remove the need for this Io extension.

in
Ok suffix
let auto_flush_callback = Ao.flush_exn in
Ao.create_rw_exn ~path ~auto_flush_callback
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice.

let* () = Mapping_file.iter mapping f in
Ao.flush prefix
let () = Mapping_file.iter_exn mapping f in
Ao.flush_exn prefix
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The result of this call isn't actually used (see _outcome above) so I'd say this can be left as-is too. Then no need for Ao.flush_exn.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed the auxiliary flush_exn (if I read the code right, we still need to raise if error).

@@ -157,24 +159,26 @@ module Worker = struct

(* Step 1. Open the files *)
[%log.debug "GC: opening files in RO mode"];
let* fm = Fm.open_ro config in
let fm = Fm.open_ro config |> Errs.raise_if_error in
Errors.finalise (fun _outcome ->
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Errors.finalise except both arguments to not raise errors.

Could you change the implementation of finalise to make it call the finiliser if f raised?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

very good point, thanks

Copy link
Member

@metanivek metanivek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM (after squashing history)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
no-changelog-needed No changelog is needed here
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants