Clarify the meaning of FLOW.close#486
Merged
samoht merged 1 commit intomirage:masterfrom Feb 17, 2016
Merged
Conversation
This patch extends the description of `FLOW.close` to include discussion of the flow state when one side has called `FLOW.close` and the other has not. Hopefully this is not actually a change in intended meaning, as the mirage tcp/ip stack already behavies this way: `FLOW.close` is implemented by sending a `FIN` to the peer which terminates only one side of the full-duplex connection. When the peer finishes transmitting all of its data -- at some arbitrary later date -- it will also send a `FIN` to close the remainder of the connection. `FLOW.close` means I will not call `write` again, so the peer can receive `Eof` once it has read all pending/buffered data. This patch clarifies that, after calling `close`, I can still call `read` to read data being written by the other side, until the other side also calls `close`. `FLOW.close` is a handshake with the peer: when the peer also calls `FLOW.close`, both threads unblock and resources associated with the connection can be freed. Signed-off-by: David Scott <dave.scott@docker.com>
Contributor
|
Thanks for the documentation work, @djs55 . This looks good to me. |
samoht
added a commit
that referenced
this pull request
Feb 17, 2016
Clarify the meaning of `FLOW.close`
Member
|
It looks so good that I HAVE to merge it :p |
Member
Author
| becomes determined, all further calls to [read flow] will result | ||
| in a [`Eof]. *) | ||
|
|
||
| (** [close flow] will flush all pending writes and signal the remote |
Contributor
There was a problem hiding this comment.
will flush -> flushes, signal -> signals
djs55
added a commit
to djs55/mirage
that referenced
this pull request
Jun 22, 2016
As reported by @dbuenzli on mirage#486 Signed-off-by: David Scott <dave@recoil.org>
djs55
added a commit
to djs55/mirage
that referenced
this pull request
Jun 22, 2016
As reported by @dbuenzli on mirage#486 Signed-off-by: David Scott <dave@recoil.org>
samoht
pushed a commit
to samoht/mirage
that referenced
this pull request
Dec 18, 2019
When removing vertexes recursively, we fold over the children. When several edges point to the same node, we would remove it, move on, check if it's orphan again (and crash). Fixes mirage#69, mirage#486
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
4 participants
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.
This patch extends the description of
FLOW.closeto include discussionof the flow state when one side has called
FLOW.closeand the otherhas not.
Hopefully this is not actually a change in intended meaning, as the
mirage tcp/ip stack already behavies this way:
FLOW.closeisimplemented by sending a
FINto the peer which terminates only oneside of the full-duplex connection. When the peer finishes transmitting
all of its data -- at some arbitrary later date -- it will also send a
FINto close the remainder of the connection.
FLOW.closemeans I will not callwriteagain, so the peer canreceive
Eofonce it has read all pending/buffered data. This patchclarifies that, after calling
close, I can still callreadtoread data being written by the other side, until the other side also
calls
close.FLOW.closeis a handshake with the peer: when the peer also callsFLOW.close, both threads unblock and resources associated with theconnection can be freed.
Signed-off-by: David Scott dave.scott@docker.com