-
-
Notifications
You must be signed in to change notification settings - Fork 745
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
Support zerocopy send #1210
Support zerocopy send #1210
Conversation
Hi @abersheeran I've invited you as a member of the Encode org. 👍 |
😀Yeah, I joined. |
I was about to ask that. 👍 Thanks! |
Do we know what the deal is with the hanging CI tests? |
It should be related with this branch. The CI is fine on uvicorn now. |
The sendfile cannot be implemented on Windows, so the test coverage cannot reach 95%. I am not familiar with whether it can be selectively skipped in this case? |
Yeah, we were adding |
Thanks for your reply, it is very helpful! |
Thank you for your pr! Now hypercorn supports zerocopysend too. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
alos I see a lot of # pragma: no cover
is there a reason ?
# Sendfile | ||
if self.allow_sendfile: # pragma: no cover | ||
# Set the buffer to 0 to avoid the problem of sending file before headers. | ||
transport.set_write_buffer_limits(0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not really comfortable with the fact that this'll change the behaviour throughout, regardless of if http.response.zerocopysend
is actually being used or not for any given request/response.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this option is not configured, the headers may be sent after the body is sent.
Okay, so this is clearly a neatly done little bit of work, nonetheless I feel like I ought to be the voice of pushback here. Personally I think that in the trade-off between functionality vs. increased complexity, increased ongoing maintenance cost, scope for bug introduction, this is a possibly poor trade-off for us. I'd perhaps be more comfortable with this if it was obvious that it didn't affect any other behaviour other that just for that one message case, but currently the write buffer change makes me uncomfortable, as does the largish footprint of the change within the |
Sendfile has to face the buffer, there seems to be no good way to avoid interference with other types of responses-we have no means to predict this behavior before zerocopysend is sent. |
Closing this as stale. |
Close #35