Skip to content

Improve test process' kill signalling #925

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

Merged
merged 2 commits into from
Mar 25, 2023

Conversation

st0012
Copy link
Member

@st0012 st0012 commented Mar 9, 2023

  1. remote_info.failed_process stores symbol but we only use the value's presence to check if the process is force-killed.
  2. The force-killed status is directly controlled by kill_safely through kill_remote_debuggee, which is directly called right before we check the status with remote_info.failed_process.

Combining the two, we can just let kill_safely and kill_remote_debuggee return the force-killed status and not storing it in remote_info, which already contains a bunch of information.

This also eliminates the need to pass test_info to kill_safely, which makes related code easier to understand and maintain.

@ko1 ko1 requested a review from ono-max March 10, 2023 08:10
@ono-max
Copy link
Member

ono-max commented Mar 20, 2023

remote_info.failed_process stores symbol, but we only use the value's presence to check if the process is force-killed.

The reason for storing the symbol is to use in console tests such as

flunk(create_message("Expected the #{name} program to finish", test_info))
. (Sorry, I think that I accidentally deleted this part before)

But it's ok to check each killing method(kill_remote_debuggee and kill_safely). Do you think that it'll be better?

@st0012
Copy link
Member Author

st0012 commented Mar 20, 2023

But it's ok to check each killing method(kill_remote_debuggee and kill_safely). Do you think that it'll be better?

Yeah definitely. Since we always check the state right after calling kill methods, using return value will be more readable and make refactoring easier.
However, I think in those cases we can also write fixed error messages based on conditions?

@st0012 st0012 force-pushed the st0012-improve-test-process-kill-signaling branch from 60f787b to 971d8c0 Compare March 20, 2023 15:57
@ono-max
Copy link
Member

ono-max commented Mar 20, 2023

However, I think in those cases we can also write fixed error messages based on conditions?

Yes, that's what I said here:
"But it's ok to check each killing method"

We can write fixed error messages by checking the state in all killing methods.

@ono-max
Copy link
Member

ono-max commented Mar 20, 2023

Yeah definitely. Since we always check the state right after calling kill methods, using return value will be more readable and make refactoring easier.

All right, Let's go with that idea.

@ono-max
Copy link
Member

ono-max commented Mar 20, 2023

I'll review the changes tomorrow. Thank you for the explanation.

@st0012
Copy link
Member Author

st0012 commented Mar 20, 2023

Yes, that's what I said here: "But it's ok to check each killing method"

Sorry I misunderstood 😅

I'll review the changes tomorrow.

Thanks!

@ono-max
Copy link
Member

ono-max commented Mar 21, 2023

How about renaming needs_kill to signal_sent?

st0012 added 2 commits March 23, 2023 00:44
1. `remote_info.failed_process` stores symbol but we only use the value's
   presence to check if the process is force-killed.
2. The force-killed status is directly controlled by `kill_safely` through
    `kill_remote_debuggee`, which is directly called right before we check
    the status with `remote_info.failed_process`.

Combining the two, we can just let `kill_safely` and `kill_remote_debuggee` to
return the force-killed status and not storing it in `remote_info`, which
already contains a bunch of information.

This also eliminates the need to pass `test_info` to `kill_safely`, which
makes related code easier to understand and maintain.
@st0012 st0012 force-pushed the st0012-improve-test-process-kill-signaling branch from 971d8c0 to 64732f6 Compare March 22, 2023 16:44
@st0012
Copy link
Member Author

st0012 commented Mar 22, 2023

How about renaming needs_kill to signal_sent?

Yeah needs_kill is not the best name. But since we also send signal in both cases, I feel signal_sent isn't clear either.
I feel force_killed matches the state's purpose better. WDYT?

@st0012 st0012 requested a review from ono-max March 22, 2023 16:47
Copy link
Member

@ono-max ono-max left a comment

Choose a reason for hiding this comment

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

Great! Thank you 👍

@ko1 ko1 merged commit 42de5fd into ruby:master Mar 25, 2023
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