GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — doc: clarify role of writable.cork() · nodejs/node@7aa7759

File tree

Expand file treeCollapse file tree
Open diff view settings
Filter options
  • doc/api
    • stream.md
Expand file treeCollapse file tree
Open diff view settings
Collapse file

‎doc/api/stream.md‎

Copy file name to clipboardExpand all lines: doc/api/stream.md
+10-7Lines changed: 10 additions & 7 deletions
  • Display the source diff
  • Display the rich diff
Original file line numberDiff line numberDiff line change
@@ -355,13 +355,16 @@ The `writable.cork()` method forces all written data to be buffered in memory.
355355
The buffered data will be flushed when either the [`stream.uncork()`][] or
356356
[`stream.end()`][stream-end] methods are called.
357357

358-
The primary intent of `writable.cork()` is to avoid a situation where writing
359-
many small chunks of data to a stream do not cause a backup in the internal
360-
buffer that would have an adverse impact on performance. In such situations,
361-
implementations that implement the `writable._writev()` method can perform
362-
buffered writes in a more optimized manner.
363-
364-
See also: [`writable.uncork()`][].
358+
The primary intent of `writable.cork()` is to accommodate a situation in which
359+
several small chunks are written to the stream in rapid succession. Instead of
360+
immediately forwarding them to the underlying destination, `writable.cork()`
361+
buffers all the chunks until `writable.uncork()` is called, which will pass them
362+
all to `writable._writev()`, if present. This prevents a head-of-line blocking
363+
situation where data is being buffered while waiting for the first small chunk
364+
to be processed. However, use of `writable.cork()` without implementing
365+
`writable._writev()` may have an adverse effect on throughput.
366+
367+
See also: [`writable.uncork()`][], [`writable._writev()`][stream-_writev].
365368

366369
##### `writable.destroy([error])`
367370
<!-- YAML

0 commit comments

Comments
0 (0)
You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.