CABI: allow dropping a readable future end with a pending write - #708
Open
rvolosatovs wants to merge 1 commit into
Open
CABI: allow dropping a readable future end with a pending write#708rvolosatovs wants to merge 1 commit into
rvolosatovs wants to merge 1 commit into
Conversation
The Explainer specifies that a component may call `future.drop-readable` before reading a value to signal loss of interest, in which case a blocked `future.write` completes with `future-write-result.dropped`. But `SharedFutureImpl.drop` asserted that any pending buffer is a `WritableBuffer`, i.e. a pending *read*, while the only pending buffer actually possible at this point is the buffer of a pending *write*: a reader cannot drop its end while its own read is pending (`CopyEnd.drop` traps while copying) and a writer cannot drop its end before the write resolves (`WritableFutureEnd.drop` traps unless DONE). Exercising this spec-legal path failed the assert instead of notifying the writer with DROPPED. Flip the assert to expect a `ReadableBuffer` (the source buffer of the pending write), make `ReadableBufferGuestImpl` actually subclass `ReadableBuffer` (it previously only derived `BufferGuestImpl`, unlike `WritableBufferGuestImpl`, which does mix in `WritableBuffer`), and add a test reproducing the scenario. Signed-off-by: Roman Volosatovs <rvolosatovs@riseup.net> Assisted-by: claude:claude-fable-5
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The Explainer specifies that a component may call
future.drop-readablebefore reading a value to signal loss of interest, in which case a blockedfuture.writecompletes withfuture-write-result.dropped. ButSharedFutureImpl.dropasserted that any pending buffer is aWritableBuffer, i.e. a pending read, while the only pending buffer actually possible at this point is the buffer of a pending write: a reader cannot drop its end while its own read is pending (CopyEnd.droptraps while copying) and a writer cannot drop its end before the write resolves (WritableFutureEnd.droptraps unless DONE). Exercising this spec-legal path failed the assert instead of notifying the writer with DROPPED.Flip the assert to expect a
ReadableBuffer(the source buffer of the pending write), makeReadableBufferGuestImplactually subclassReadableBuffer(it previously only derivedBufferGuestImpl, unlikeWritableBufferGuestImpl, which does mix inWritableBuffer), and add a test reproducing the scenario.