-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
outgoing-body flush behaviour states #80
Comments
The specific issue I hit here was that |
Just discussed this with @elliottt - In case 1, we don't want to change the meaning of flush to mean nothing. Instead, calling One valid implementation of the body stream is permitting no buffering at all, so in state 1 it would never be write ready, and in state 2 it would only become write ready for whatever the underlying network layer buffers. That isn't a very realistic implementation, though, so we expect most implementations will permit some amount of buffering in both states 1 and 2, where once that buffering is full check-write returns 0 until the buffer is emptied. In state 1, either filling the buffer or calling flush will make the check-write return 0 until the body is sent and emptied, and in state 2 it would still need the network layer to empty it. |
This sounds like a sensible direction and the right set of tradeoffs to make to me. |
As far as I can tell,
outgoing-body
's stream can exist in two different states:In state (1), does the subscribe just fail if we exceed the high watermark? Or is the high watermark functionality also disabled?
Effectively, does that mean that a transition from state (1) to state (2) change it from permitting writes over the high watermark to not?
The text was updated successfully, but these errors were encountered: