-
Notifications
You must be signed in to change notification settings - Fork 30
pidwait: optimize & cross-platform #400
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
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: FurryR <[email protected]>
Thank you for your contribution, I will start reviewing soon :) |
Hm, at least on my machine (using Linux) your changes make the test
|
Signed-off-by: FurryR <[email protected]>
Signed-off-by: FurryR <[email protected]>
Fixed a bunch of things, now tests can be passed on Output of
Requiring further tests on Windows and OpenBSD. |
Signed-off-by: FurryR <[email protected]>
sorry that is my fault. Signed-off-by: FurryR <[email protected]>
Signed-off-by: FurryR <[email protected]> Co-authored-by: Daniel Hofstetter <[email protected]>
Sorry for replying late. I am working on it right now. |
Signed-off-by: FurryR <[email protected]>
Signed-off-by: FurryR <[email protected]>
pub(crate) fn wait( | ||
procs: &[ProcessInformation], | ||
timeout: Option<Duration>, | ||
) -> Result<Option<()>, std::io::Error> { |
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.
What's the reason for using Option<()>
? Why not use ()
?
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 thought that it would be better if we can pass exceptions rather than just unwrap
.
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.
Hm, I don't understand what you mean :| I think we are talking about different things. Maybe my question was too imprecise?
My question is: why do you use Result<Option<()>, std::io::Error>
instead of Result<(), std::io::Error>
as return type?
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 think using Option<()>
is unnecessary because the meaning of this Option
is to indicate something there
or nothing there
, and it's clear that this function doesn't need that meaning; it only needs to know whether an error occurred
procs: &[ProcessInformation], | ||
timeout: Option<Duration>, | ||
) -> Result<Option<()>, std::io::Error> { | ||
if !procs.is_empty() { |
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.
A detail: I would drop the !
and swap the if
and else
blocks, it's a little bit easier to read.
Co-authored-by: Daniel Hofstetter <[email protected]>
use std::time::Duration; | ||
use uu_pgrep::process::ProcessInformation; | ||
|
||
pub fn wait(procs: &[ProcessInformation], timeout: Option<Duration>) -> Result<Option<()>> { |
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.
use std::time::Duration; | ||
use uu_pgrep::process::ProcessInformation; | ||
|
||
pub fn wait(procs: &[ProcessInformation], timeout: Option<Duration>) -> Result<Option<()>> { |
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.
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 noticed that there are some unsafe
block in this file, and cloud you please add comments to explain why it's safety here? :)
https://github.com/uutils/coreutils/blob/main/CONTRIBUTING.md#unsafe
Resolves #399 (partially).
Needs to be reviewed before merge as it contains untested code. However it seems that at least the implementation for Linux works fine.