Skip to content

doc: edit for concision #17891

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.

Sign up for GitHub

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

Closed
Trott wants to merge 7 commits into from
Closed

doc: edit for concision #17891

Changes from 1 commit
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
8374657
doc: edit for concision
Trott Dec 28, 2017
465874d
squash
Trott Dec 30, 2017
ba7d74d
squash
Trott Dec 30, 2017
71af80b
squash
Trott Dec 30, 2017
8d2af16
squash
Trott Dec 30, 2017
004033a
squash
Trott Dec 30, 2017
ba1195b
squash
Trott Dec 30, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
squash
  • Loading branch information
@Trott
Trott committed Dec 30, 2017
commit ba7d74d6b6de50396f1cc597a9c34896d70cdd67
89 changes: 40 additions & 49 deletions doc/api/process.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -377,52 +377,43 @@ process.on('SIGTERM', handle);
An easy way to send the `SIGINT` signal is with `<Ctrl>-C` in most terminal
Copy link
Copy Markdown
Contributor

@vsemozhetbyt vsemozhetbyt Dec 28, 2017

Choose a reason for hiding this comment

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

In this fragment we have:
<Ctrl>-C
CTRL+C
<Ctrl>+<Break>
Do we need to unify this?

Copy link
Copy Markdown
Member Author

@Trott Trott Dec 30, 2017

Choose a reason for hiding this comment

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

The two mentions of Ctrl-C are redundant, so I'd be inclined to remove this one. Which I'll do.

I made the other two instances consistent. Probably worth figuring out what (if any) universal standard there is for such things (like maybe see what RFCs do), document it in the style guide, and apply it across all docs. But not in this PR. :-D

programs.

`SIGUSR1` is reserved by Node.js to start the [debugger][]. It's possible to
install a listener but doing so will _not_ stop the debugger from starting.

`SIGTERM` and `SIGINT` have default handlers on non-Windows platforms that
resets the terminal mode before exiting with code `128 + signal number`. If
one of these signals has a listener installed, its default behavior will be
removed (Node.js will no longer exit).

`SIGPIPE` is ignored by default. It can have a listener installed.

`SIGHUP` is generated on Windows when the console window is closed, and on
other platforms under various similar conditions, see signal(7). It can have a
listener installed, however Node.js will be unconditionally terminated by
Windows about 10 seconds later. On non-Windows platforms, the default
behavior of `SIGHUP` is to terminate Node.js, but once a listener has been
installed its default behavior will be removed.

`SIGTERM` is not supported on Windows, it can be listened on.

`SIGINT` from the terminal is supported on all platforms, and can usually be
generated with `CTRL+C` (though this may be configurable). It is not generated
when terminal raw mode is enabled.

`SIGBREAK` is delivered on Windows when `<Ctrl>+<Break>` is pressed, on
non-Windows platforms it can be listened on, but there is no way to send or
generate it.

`SIGWINCH` is delivered when the console has been resized. On Windows, this
will only happen on write to the console when the cursor is being moved, or
when a readable tty is used in raw mode.

`SIGKILL` cannot have a listener installed, it will unconditionally terminate
Node.js on all platforms.

`SIGSTOP` cannot have a listener installed.

`SIGBUS`, `SIGFPE`, `SIGSEGV` and `SIGILL`, when not raised artificially
using kill(2), inherently leave the process in a state from which it is not
safe to attempt to call JS listeners. Doing so might lead to the process
hanging in an endless loop, since listeners attached using `process.on()` are
called asynchronously and therefore unable to correct the underlying problem.

Windows does not support sending signals, but Node.js offers some emulation with
[`process.kill()`][], and [`subprocess.kill()`][]. Sending signal `0` can be
used to test for the existence of a process. Sending `SIGINT`, `SIGTERM`, and
`SIGKILL` cause the unconditional termination of the target process.
* `SIGUSR1` is reserved by Node.js to start the [debugger][]. It's possible to
install a listener but doing so will _not_ stop the debugger from starting.
* `SIGTERM` and `SIGINT` have default handlers on non-Windows platforms that
resets the terminal mode before exiting with code `128 + signal number`. If
one of these signals has a listener installed, its default behavior will be
removed (Node.js will no longer exit).
* `SIGPIPE` is ignored by default. It can have a listener installed.
* `SIGHUP` is generated on Windows when the console window is closed, and on
other platforms under various similar conditions, see signal(7). It can have a
listener installed, however Node.js will be unconditionally terminated by
Windows about 10 seconds later. On non-Windows platforms, the default
behavior of `SIGHUP` is to terminate Node.js, but once a listener has been
installed its default behavior will be removed.
* `SIGTERM` is not supported on Windows, it can be listened on.
* `SIGINT` from the terminal is supported on all platforms, and can usually be
generated with `CTRL+C` (though this may be configurable). It is not generated
when terminal raw mode is enabled.
* `SIGBREAK` is delivered on Windows when `<Ctrl>+<Break>` is pressed, on
non-Windows platforms it can be listened on, but there is no way to send or
generate it.
* `SIGWINCH` is delivered when the console has been resized. On Windows, this
will only happen on write to the console when the cursor is being moved, or
when a readable tty is used in raw mode.
* `SIGKILL` cannot have a listener installed, it will unconditionally terminate
Node.js on all platforms.
* `SIGSTOP` cannot have a listener installed.
* `SIGBUS`, `SIGFPE`, `SIGSEGV` and `SIGILL`, when not raised artificially
using kill(2), inherently leave the process in a state from which it is not
safe to attempt to call JS listeners. Doing so might lead to the process
hanging in an endless loop, since listeners attached using `process.on()` are
called asynchronously and therefore unable to correct the underlying problem.

*Note*: Windows does not support sending signals, but Node.js offers some
emulation with [`process.kill()`][], and [`subprocess.kill()`][]. Sending
signal `0` can be used to test for the existence of a process. Sending `SIGINT`,
`SIGTERM`, and `SIGKILL` cause the unconditional termination of the target
process.

## process.abort()
<!-- YAML
Expand Down Expand Up @@ -684,9 +675,9 @@ If there are specific reasons to use `process.dlopen()` (for instance,
to specify dlopen flags), it's often useful to use [`require.resolve()`][]
to look up the module's path.

An important drawback when calling `process.dlopen()` is that the `module`
instance must be passed. Functions exported by the C++ Addon will be accessible
via `module.exports`.
*Note*: An important drawback when calling `process.dlopen()` is that the
`module` instance must be passed. Functions exported by the C++ Addon will
be accessible via `module.exports`.

The example below shows how to load a C++ Addon, named as `binding`,
that exports a `foo` function. All the symbols will be loaded before
Expand Down