-
-
Notifications
You must be signed in to change notification settings - Fork 603
Feature/status line errors #1879
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?
Changes from 3 commits
f2a43a7
90edaa4
0bc5677
12fbcd2
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -19,6 +19,7 @@ in the source distribution for its full text. | |
| #include <string.h> | ||
| #include <time.h> | ||
| #include <sys/resource.h> | ||
| #include <errno.h> | ||
|
|
||
| #include "CRT.h" | ||
| #include "Hashtable.h" | ||
|
|
@@ -901,14 +902,22 @@ bool Process_rowChangePriorityBy(Row* super, Arg delta) { | |
| return Process_setPriority(this, (int)this->nice + delta.i); | ||
| } | ||
|
|
||
| static bool Process_sendSignal(Process* this, Arg sgn) { | ||
| return kill(Process_getPid(this), sgn.i) == 0; | ||
| static bool Process_sendSignal(Process* this, sendSignalContext* ctx) { | ||
| if (kill(Process_getPid(this), ctx->sgn ) != 0) { | ||
| int e = errno; | ||
| if (e != ESRCH) { | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why filter this specific error code?
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ESRCH is often a silent failure in other projects/management scripting. Since no process found means the process exited before the kill command sent, the process ended, just not from kill. Signaling an error could cause confusion to users and add noise that overshadows more useful errors. This is a UX decision for usability and clarity as ESRCH errors do not facilitate any user actions, and processes exiting is normal on Unix systems.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. But you stop the loop instead of continue. This doesn't look like you are ignoring the error, but like you are hiding the error deliberately from user.
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To the end user the ESRCH/successful kill are the same, so I break the loop to return true to the caller. If it is any other error then it gets displayed on the error bar. Edit: I misspoke. We treat ESRCH as failure, but treat it as one not worth having an error displayed. If htop wants all errors surfaced with no filtering I can do that.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. htop can kill multiple processes in a loop. There's a tag feature (Space key) to select multiple processes, then press the
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @DeltachangeOG I admit I didn't test myself, but, since htop can kill multiple processes at once, shouldn't the status bar messages show a list of processes that failed to kill? The message could look like:
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ESRCH currently returns false, that behavior is maintained. We could not filter out ESRCH, and maintain the return of False on any failure, but with an error message or Treat ESRCH as success due to the end user goal being completed either by kill or the process exiting for other reasons. I lean toward treating ESRCH as success here since from the user’s perspective the process is already gone (same end state as a successful kill). Please let me know if you have additional thoughts.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The return value for a loop callback function should indicate whether the loop should continue. The general idea (if the return type wasn't boolean) is that no error = continre loop, and error = break loop and return error.
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I didn't want to alter the structure that was already in place, so I maintained current behavior of the call, and just added error details when there was a failure. I can queue errors, or display multiple errors, or we can have a hierarchy of errors and only display the "top" error. If we want failures to break the loop and display an error then I would vote we treat ESRCH as success for those semantics. I tried to implement this feature with as little impact on current behavior as possible, however I am happy to implement whatever direction the maintainers want for this.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't know what the maintainers would decide, but I personally don't like having a |
||
| ctx->savedErrno = e; | ||
| } | ||
| return false; | ||
| } | ||
| return true; | ||
| } | ||
|
|
||
| bool Process_rowSendSignal(Row* super, Arg sgn) { | ||
| bool Process_rowSendSignal(Row* super, Arg arg) { | ||
| Process* this = (Process*) super; | ||
| assert(Object_isA((const Object*) this, (const ObjectClass*) &Process_class)); | ||
| return Process_sendSignal(this, sgn); | ||
| sendSignalContext* ctx = (sendSignalContext*) arg.v; | ||
| return Process_sendSignal(this, ctx); | ||
| } | ||
|
|
||
| int Process_compare(const void* v1, const void* v2) { | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.