-
Notifications
You must be signed in to change notification settings - Fork 415
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
Conversation
ab34ea5
to
30c560c
Compare
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 -->
30c560c
to
f3bdf77
Compare
} | ||
|
||
module Result = struct | ||
type nonrec process = t |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why nonrec?
There was a problem hiding this 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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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:
- We make sure that we never read the file unless we need the output
- Subsequent reads are free
- 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.
Refactor process handling. This is has two purposes:
At a high level, the refactoring does the following:
[Process.Result.t]
forgetting to clean it up or reading it after they've been deleted.
Signed-off-by: Rudi Grinberg me@rgrinberg.com