You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Depends on #3784
The proposed new Publisher:
1. does not use the event loop to manage AsyncRecord dependencies
2. performs as much work as possible synchronously
2. uses separate sets to store pending vs ready AsyncRecords
3. does not use `Promise.race`
-- No event loop for managing AsyncRecord dependencies
The current Publisher wraps every AsyncRecord result in a promise that only resolves after the parent AsyncRecord resolves. If multiple items within a stream are released for publishing because their parent has just been published, the stream cannot be in its entirety until after all of these promises unwind.
The new Publisher keeps track of dependencies manually. When an AsyncRecord is pushed by the publisher, all of its dependent AsyncRecords are synchronously pushed, repeating as necessary, without using the event loop.
In general, the new publisher aims to perform as much work as possible synchronously.
-- Separate sets for pending vs ready AsyncRecords
The current publisher inspects all pending AsyncRecords whenever any of them resolves. All that are completed are added to the response. The new Publisher moves AsyncRecords from the pending set to the ready set as they are pushed, so that on each call to next, only the ready set must be iterated.
As a side-effect of this change, the incremental array is ordered by which items are ready for delivery first, and not by the initial document.
This seems like a worthwhile tradeoff, and is still adherent to the spec, as far as I can tell.
-- No `Promise.race`
The old Publisher uses `Promise.race` as the trigger to determine whether payloads are ready. The new Publisher uses a single triggering promise that is triggered whenever an AsyncRecord is pushed, and then reset. This may be beneficial as the implementation of `Promise.race` within V8 has a known memory leak for long-running promises. (see https://bugs.chromium.org/p/v8/issues/detail?id=9858). An alternative would be to utilize @brainkim 's memory-safe version detailed in that issue.
0 commit comments