-
-
Notifications
You must be signed in to change notification settings - Fork 419
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
Refactor tokio_postgres::Connection
implementation
#1066
base: master
Are you sure you want to change the base?
Conversation
# Conflicts: # tokio-postgres/src/connection.rs
What is the purpose of these changes? |
@sfackler Thanks for the quick reply. These changes should allow to process something like this more efficiently: let (client, connection) =
tokio_postgres::connect(..).await?;
let rc_client = Rc::new(client);
tokio::spawn_local(move || {
rc_client.clone().query(..)
})
tokio::spawn_local(move || {
rc_client.clone().query(..)
}) without blocking Also, now Private docs updated to make code a little bit readable. p.s. All changes are minor and doesn't break the public API, only internal implementation is changed. |
What blocking is happening before this change?
In what context would a message not be written? |
But there can be a situation when socket already has a full response (all its messages) and some messages of another one. In this case we can try to send a part of the second response within current poll:
I think this should be more efficient, because we don't have a guarantee that runtime will poll the
If we assume that
In case when p.s. Also found that both |
A sufficiently fast server could cause that logic to OOM by giving it an unbounded amount of messages to buffer.
Efficiency claims should be measured, not assumed.
The next poll of the connection will continue to drive the flush.
Because there aren't any vectored writes happening in the client AFAIK. |
Minor changes improving
tokio_postgres::Connection
implementation:Connection::stream
polling independent from polling pending requests/responses;Connection::poll_read
now ensures the written messages was flushed, before sending the next ones;