Repository navigation
Rename possibly offensive terminology in child_process #14444
Description
Activity
Impact
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?
Reacted by Anna Henningsen+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
Reacted by JakubReacted by AlmenonReacted by JakubReacted by Tobias Nießen@fastman It maps 1-to-1 to the system call of the same name.
Reacted by Benjamin Gruenbaum, Tobias Nießen, Gibson Fahnestock, Ron Korving, Nikita Skovoroda, Daniel Peterson, Tuan Anh Tran, Hunter Loftis and AlmenonWhen 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 -
killis 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.Reacted by Tobias Nießen, Jake Niemiec, Hunter Loftis and Michał Wadas@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 thatkillfunction 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:
- The wording should not be disturbing.
- Maintaining compatibility with older Node.js versions.
- Maintaining consistent terminology to help developers familiar with other environments transition to Node.js.
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
sendSignalalias as that is the more precise name, but am -1 against deprecating or removingkill. Whether Node.js'skillfunction is a vanilla wrapper of the syscall, or does it do a bit more, is too semantical to be relevant IMO.Reacted by Tobias Nießen, Anna Henningsen, Benjamin Gruenbaum, Peter Asztalos and Hunter LoftisReacted by Anna Henningsen and Benjamin Gruenbaum@TimothyGu What do you think about changing the wording in the documentation?
childvariable 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 aboutsending signalto aprocess+1 for the alias of course!
I'd like to see the discussion about the possibility of renaming
.killor adding an alias moved to another (new) thread if you're fine with it @fastman .Reacted by Tobias Nießen, Peter Asztalos and fastman@benjamingr has this progressed? If not might I suggest a solution similar to #14578 — replace the term
childwithsubprocessthen the verb becomes way less significant.Reacted by Sharababy and Michał Wadas@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.
Reacted by Refael AckermannThis was resolved a while ago.
Currently, we use the terminology "Child died" when child processed get terminated.
We discussed the terminology in #14293 (comment) , copying my comment from there:
@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.