Skip to content
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

Jump to bottom

doc: simplify sentences that use "considered" #18095

Closed
wants to merge 1 commit into from
Closed

doc: simplify sentences that use "considered" #18095

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
8 changes: 4 additions & 4 deletions doc/api/child_process.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1124,10 +1124,10 @@ process.send({ foo: 'bar', baz: NaN });
Child Node.js processes will have a [`process.send()`][] method of their own that
allows the child to send messages back to the parent.

There is a special case when sending a `{cmd: 'NODE_foo'}` message. All messages
containing a `NODE_` prefix in its `cmd` property are considered to be reserved
for use within Node.js core and will not be emitted in the child's
[`process.on('message')`][] event. Rather, such messages are emitted using the
There is a special case when sending a `{cmd: 'NODE_foo'}` message. Messages
containing a `NODE_` prefix in the `cmd` property are reserved for use within
Node.js core and will not be emitted in the child's [`process.on('message')`][]
event. Rather, such messages are emitted using the
`process.on('internalMessage')` event and are consumed internally by Node.js.
Applications should avoid using such messages or listening for
`'internalMessage'` events as it is subject to change without notice.
Expand Down
2 changes: 1 addition & 1 deletion doc/api/http.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -622,7 +622,7 @@ Once a socket is assigned to this request and is connected
added: v0.5.9
-->

* `timeout` {number} Milliseconds before a request is considered to be timed out.
* `timeout` {number} Milliseconds before a request times out.
Copy link
Member

Choose a reason for hiding this comment

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

Unrelated but I think this description is a bit misleading. This timeout expires only after x millisecond of inactivity on the socket. It's possible that a data chunk resets the timeout right before it expires without completing the request.

I'll open a separate PR if I remember :)

Copy link
Member Author

Choose a reason for hiding this comment

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

@lpinca Perhaps you or I can add a squash-able commit here to change it to Milliseconds of inactivity before a request times out.?

* `callback` {Function} Optional function to be called when a timeout occurs. Same as binding to the `timeout` event.

Once a socket is assigned to this request and is connected
Expand Down
4 changes: 2 additions & 2 deletions doc/api/readline.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -60,8 +60,8 @@ The `'close'` event is emitted when one of the following occur:

The listener function is called without passing any arguments.

The `readline.Interface` instance should be considered to be "finished" once
the `'close'` event is emitted.
The `readline.Interface` instance is finished once the `'close'` event is
emitted.

### Event: 'line'
<!-- YAML
Expand Down
3 changes: 1 addition & 2 deletions doc/guides/maintaining-V8.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -29,8 +29,7 @@ For example, at the time of this writing:
released as part of the Chromium **canary** builds. This branch will be
promoted to beta next when V8 5.5 ships as stable.

All older branches are considered **abandoned**, and are not maintained by the
V8 team.
All older branches are abandoned and are not maintained by the V8 team.

### V8 merge process overview

Expand Down