Currently, we use the terminology "Child died" when child processed get terminated.
We discussed the terminology in https://github.com/nodejs/node/pull/14293#discussion_r127606290 , copying my comment from there:
I'm usually the last one to worry about that sort of stuff - but is it possible this terminology is offensive? If we swapped out other trigger references I think it would be nice to have a code base without dead children.
@jasnell suggested we change the terminology to "Child exited". I agree it's better terminology, in general I think we should avoid irrelevant stuff that might cause people to feel uneasy (like death related terminology in code) where we can and I think it could help keep the project friendly and inclusive.
Since it is internal code, I think we can just remove it safely from here (and other places). To be on the safe side I did a GitHub search. Looking at https://github.com/search?l=JavaScript&q=%22Child+died%22&type=Code&utf8=%E2%9C%93 - there certainly are usages of the terminology (or have a fork of node in their repo), but nothing relying on anything internal (I went through the 'child dead' search too). I don't see anyone relying on it or using it any way. (_Warning_, the search results contain some jokes one might consider very offensive).
I'm confident we can do it as semver-patch in all cases that are test related. Any objections?
+1 for semver-patch.
Sounds good, just make sure not to use "exited" unless it specifically refers to a process exiting. Processes (on unix) can terminate via exit, or terminate via signal. Terminate is the generic technical term used in the man pages to cover both cases, see discussion of WIFEXITED vs WIFSIGNALED in http://man7.org/linux/man-pages/man2/waitpid.2.html.
Hi,
When we are on this, what do you think about replacing
child.kill([signal])
[1]
with
child.sendSignal([signal])
?
Killing the child just does not sound right :/
[1] https://nodejs.org/dist/latest-v6.x/docs/api/child_process.html#child_process_child_kill_signal
@fastman It maps 1-to-1 to the system call of the same name.
@fastman
When we are on this, what do you think about replacing
I'm with @bnoordhuis here, while I'm not a fan of the name unix chose for signals - kill
is the operating system commend and I don't think we can replace it. I'd rather avoid offensive terminology as much as possible - but not at the expense of changing operating system terms.
@benjamingr
I understand, but should't we strive to be a better community?
In my opinion, saying that something was done wrong in the past, sticking to it and repeating mistakes should not be a way to go.
Maybe at least we could change the wording in the documentation? [1]
@bnoordhuis
I'm not sure that it maps 1-1 to the system call - I think that kill
function in Node.JS does a little bit more.
sticking to it and repeating mistakes should not be a way to go
Nor should creating a set of "Node.js-specific terminology" against established tradition be our modus operandi, IMHO. There are multiple duties (in a deontological sense) at play here:
Where we draw the line between 1 and 2/3 is of course the good ol' problem of virtue ethics.
The OP does not have concern 2), which is a big reason why I am in support of it. It also does not correspond to a syscall or UNIX command, rather derived artificially.
The "suicide" flag did have concern 2) in play, but since again it does not correspond to a syscall, and the word is somewhat more disturbing than kill
(IMO) it passed the threshold.
Of course, this is all subjective, but as multiple members of the community have shown the proposal does have objections against it.
I would be okay with adding a sendSignal
alias as that is the more precise name, but am -1 against deprecating or removing kill
. Whether Node.js's kill
function is a vanilla wrapper of the syscall, or does it do a bit more, is too semantical to be relevant IMO.
@TimothyGu What do you think about changing the wording in the documentation? child
variable can be replaced with any name.
kill(2)
manual is more precise in that matter and avoids confusing terminology. Apart from the name itself it is about sending signal
to a process
+1 for the alias of course!
I'd like to see the discussion about the possibility of renaming .kill
or adding an alias moved to another (new) thread if you're fine with it @fastman .
@benjamingr has this progressed? If not might I suggest a solution similar to https://github.com/nodejs/node/pull/14578 — replace the term child
with subprocess
then the verb becomes way less significant.
@refack that sounds like a good idea. To be honest I completely forgot about this issue 0_0
If you want to (and have time) to PR this be my guest - otherwise probably next weekend.
This was resolved a while ago.
Most helpful comment
@fastman It maps 1-to-1 to the system call of the same name.