Skip to content

Commit ac5cdd6

Browse files
jasnellcodebytere
authored andcommittedJun 7, 2020
doc: add warnings about transferring Buffers and ArrayBuffer
Signed-off-by: James M Snell <jasnell@gmail.com> PR-URL: #33252 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Mathias Buus <mathiasbuus@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
1 parent 82da74b commit ac5cdd6

File tree

1 file changed

+46
-0
lines changed

1 file changed

+46
-0
lines changed
 

‎doc/api/worker_threads.md

+46
Original file line numberDiff line numberDiff line change
@@ -393,6 +393,51 @@ posting without having side effects.
393393
For more information on the serialization and deserialization mechanisms
394394
behind this API, see the [serialization API of the `v8` module][v8.serdes].
395395

396+
#### Considerations when transferring TypedArrays and Buffers
397+
398+
All `TypedArray` and `Buffer` instances are views over an underlying
399+
`ArrayBuffer`. That is, it is the `ArrayBuffer` that actually stores
400+
the raw data while the `TypedArray` and `Buffer` objects provide a
401+
way of viewing and manipulating the data. It is possible and common
402+
for multiple views to be created over the same `ArrayBuffer` instance.
403+
Great care must be taken when using a transfer list to transfer an
404+
`ArrayBuffer` as doing so will cause all `TypedArray` and `Buffer`
405+
instances that share that same `ArrayBuffer` to become unusable.
406+
407+
```js
408+
const ab = new ArrayBuffer(10);
409+
410+
const u1 = new Uint8Array(ab);
411+
const u2 = new Uint16Array(ab);
412+
413+
console.log(u2.length); // prints 5
414+
415+
port.postMessage(u1, [u1.buffer]);
416+
417+
console.log(u2.length); // prints 0
418+
```
419+
420+
For `Buffer` instances, specifically, whether the underlying
421+
`ArrayBuffer` can be transferred or cloned depends entirely on how
422+
instances were created, which often cannot be reliably determined.
423+
424+
Depending on how a `Buffer` instance was created, it may or may
425+
not own its underlying `ArrayBuffer`. An `ArrayBuffer` must not
426+
be transferred unless it is known that the `Buffer` instance
427+
owns it. In particular, for `Buffer`s created from the internal
428+
`Buffer` pool (using, for instance `Buffer.from()` or `Buffer.alloc()`),
429+
transferring them is not possible and they will always be cloned,
430+
which sends a copy of the entire `Buffer` pool.
431+
This behavior may come with unintended higher memory
432+
usage and possible security concerns.
433+
434+
See [`Buffer.allocUnsafe()`][] for more details on `Buffer` pooling.
435+
436+
The `ArrayBuffer`s for `Buffer` instances created using
437+
`Buffer.alloc()` or `Buffer.allocUnsafeSlow()` can always be
438+
transferred but doing so will render all other existing views of
439+
those `ArrayBuffer`s unusable.
440+
396441
### `port.ref()`
397442
<!-- YAML
398443
added: v10.5.0
@@ -754,6 +799,7 @@ active handle in the event system. If the worker is already `unref()`ed calling
754799
[`'exit'` event]: #worker_threads_event_exit
755800
[`AsyncResource`]: async_hooks.html#async_hooks_class_asyncresource
756801
[`Buffer`]: buffer.html
802+
[`Buffer.allocUnsafe()`]: buffer.html#buffer_class_method_buffer_allocunsafe_size
757803
[`ERR_MISSING_MESSAGE_PORT_IN_TRANSFER_LIST`]: errors.html#errors_err_missing_message_port_in_transfer_list
758804
[`ERR_WORKER_NOT_RUNNING`]: errors.html#ERR_WORKER_NOT_RUNNING
759805
[`EventEmitter`]: events.html

0 commit comments

Comments
 (0)
Please sign in to comment.