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

refactor: process handling #8113

Merged
merged 1 commit into from
Jul 12, 2023
Merged

Conversation

rgrinberg
Copy link
Member

Refactor process handling. This is has two purposes:

  • Simplify the implementation and make it easier to follow
  • Prepare it for making it friendly for action runners

At a high level, the refactoring does the following:

  • Introuce a type for a running process [Process.t]
  • Introduce a type for the result of running a process
    [Process.Result.t]
  • Introduce a type for handling stdout/stderr without accidentally
    forgetting to clean it up or reading it after they've been deleted.

Signed-off-by: Rudi Grinberg me@rgrinberg.com

@rgrinberg rgrinberg force-pushed the ps/rr/refactor__process_handling branch 2 times, most recently from ab34ea5 to 30c560c Compare July 5, 2023 15:00
Refactor process handling. This is has two purposes:

* Simplify the implementation and make it easier to follow
* Prepare it for making it friendly for action runners

At a high level, the refactoring does the following:

* Introuce a type for a running process [Process.t]
* Introduce a type for the result of running a process
  [Process.Result.t]
* Introduce a type for handling stdout/stderr without accidentally
  forgetting to clean it up or reading it after they've been deleted.

Signed-off-by: Rudi Grinberg <me@rgrinberg.com>

<!-- ps-id: f4da9d0f-581a-4fe3-9125-8fa50ab438f8 -->
@rgrinberg rgrinberg force-pushed the ps/rr/refactor__process_handling branch from 30c560c to f3bdf77 Compare July 5, 2023 15:46
}

module Result = struct
type nonrec process = t
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why nonrec?

Copy link
Collaborator

@dkalinichenko-js dkalinichenko-js left a comment

Choose a reason for hiding this comment

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

Mostly LGTM, but some parts are hard to judge without seeing the .mli.


type t =
{ on_success : Action_output_on_success.t
; mutable unexpected_output : bool
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't like mutable fields here. For now, it's fine because this type is not exposed anywhere in the .mli, but it seems wrong to provide an interface with it.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, it's a bit ugly, but I encourage you to understand the old code though :)

We handle 3 separate concerns with mutation:

  1. We make sure that we never read the file unless we need the output
  2. Subsequent reads are free
  3. If we need to swallow the output, we make sure the output we read is always empty.

It also allows us to introduce an optimization:

To check if the output is empty, we don't need to read the file. We can just get its size using stat. That saves an open/close on empty files which should be quite common.

@rgrinberg rgrinberg merged commit a0145b2 into main Jul 12, 2023
@rgrinberg rgrinberg deleted the ps/rr/refactor__process_handling branch July 12, 2023 21:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants