Skip to content
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

Async-ify the API #232

Merged
merged 45 commits into from Dec 30, 2019
Merged

Async-ify the API #232

merged 45 commits into from Dec 30, 2019

Conversation

Marwes
Copy link
Collaborator

@Marwes Marwes commented Aug 21, 2019

With async/await we can take references in the async api and avoid clones and
moves in many cases.

Based on #231

@Marwes
Copy link
Collaborator Author

Marwes commented Aug 21, 2019

Outcome of rust-lang/rust#63778 might affect what kind of API we want for the query builders as they are quite inconvenient atm

@badboy badboy mentioned this pull request Aug 24, 2019
3 tasks
@Marwes Marwes force-pushed the async_await_api branch 3 times, most recently from 5c7c8b4 to c5134d8 Compare October 11, 2019 09:41
@Marwes
Copy link
Collaborator Author

Marwes commented Oct 11, 2019

I changed the async ConnectionLike trait to take &Cmd/&Pipeline instead of the encoded vector. Should make it easier to implement the sharding calculation on the redis-cluster side. Might be a good change for the sync interface as well.

https://github.com/mitsuhiko/redis-rs/pull/232/files/d20c2b23af8211adf38cc4e044659b5cc0968e49..b7561257a23d575803bbece33c00cb9453a11cf4

@djc
Copy link
Contributor

djc commented Oct 28, 2019

Are there any plans around merging/releasing an alpha with this?

@Marwes
Copy link
Collaborator Author

Marwes commented Oct 29, 2019

This is probably as good as I can make this PR for now so 👍 on releasing an alpha with this. Could use a review however.

Copy link
Contributor

@djc djc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here's a drive-by review. Do with it whatever you like. 👍 It ended up mostly being about style issues. The core async/await stuff looks broadly right to me.

benches/bench_basic.rs Outdated Show resolved Hide resolved
benches/bench_basic.rs Show resolved Hide resolved
benches/bench_basic.rs Outdated Show resolved Hide resolved
src/aio.rs Outdated Show resolved Hide resolved
src/aio.rs Show resolved Hide resolved
src/client.rs Outdated Show resolved Hide resolved
src/client.rs Outdated Show resolved Hide resolved
src/cmd.rs Show resolved Hide resolved
src/parser.rs Show resolved Hide resolved
src/types.rs Show resolved Hide resolved
@dbrgn
Copy link
Contributor

dbrgn commented Oct 29, 2019

Right now the README still states:

Note: redis-rs requires at least Rust 1.27.

That would probably need to be changed, right?

@djc
Copy link
Contributor

djc commented Oct 30, 2019

FWIW, I've just finished my work on updating the bb8 connection pool to async/await, which includes support for this branch in the bb8-redis crate.

@dbrgn
Copy link
Contributor

dbrgn commented Oct 31, 2019

I'm currently trying out your branch and will post feedback here as I gain more experience with the library.

The first thing that I noticed: The difference between redis::aio::Connection and redis::aio::SharedConnection is not really clear, some more explanatory docs (either in the main module, in the get_async_connection / get_shared_async_connection_with_executor methods or in the connection structs) would be great! Especially some guidance on when to use which connection might be useful.

(If I understand it correctly, with Connection you might have multiple connections in a single executor while SharedConnection is something similar to a thread-local, but in the context of the executor. Is that correct? If yes, what does it mean in the case of a thread pool executor, will there be a single connection for all threads, or will there be a connection per thread?)

@Marwes
Copy link
Collaborator Author

Marwes commented Oct 31, 2019

Thanks for the feedback @dbrgn . I renamed it to multiplexed (like https://stackexchange.github.io/StackExchange.Redis/PipelinesMultiplexers.html) instead of shared which should explain it better, and added some more documentation.

@dbrgn
Copy link
Contributor

dbrgn commented Oct 31, 2019

Thanks @Marwes! The new name makes it clearer 🙂

Copy link
Contributor

@dbrgn dbrgn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does the multiplexed connection deal with blocking operations like BLPOP, BRPOP and BRPOPLPUSH? In the docs for the SE.Redis library it's mentioned that those are explicitly not supported when multiplexing. However, in this case since the redis commands are strings we cannot prevent the user from calling those commands, right?

src/client.rs Outdated
/// A multiplexed connection can be cloned, allowing requests to be be sent concurrently
/// on the same underlying connection (tcp/unix socket).
///
/// Requires an executor to spawn a task that drives the underlying connection.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if a note should be added that get_multiplexed_async_connection is also available, but only if the executor feature is enabled. Might be a bit hard to discover otherwise.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed it around a bit to be tokio-executor instead and mentioned the feature.

@Marwes
Copy link
Collaborator Author

Marwes commented Oct 31, 2019

However, in this case since the redis commands are strings we cannot prevent the user from calling those commands, right?

We could prevent those and return Err, but I don't think it is worth it. It could still be useful, and the only thing that happens for the other requests is that they will be delayed or not return, but that could happen regardless (network problems etc) so everything still works.

@dbrgn
Copy link
Contributor

dbrgn commented Oct 31, 2019

Yep, since the API is rather lower-level we can probably ignore this. However, documenting the limitation in the MultiplexedConnection would probably be a good idea!

@elpiel
Copy link
Contributor

elpiel commented Nov 7, 2019

Hey all! Rust 1.39 is out and async/await is in stable! What is the status of the PR?

@Marwes
Copy link
Collaborator Author

Marwes commented Nov 7, 2019

Waiting for an alpha of tokio which uses futures-0.3 seems prudent (tokio-rs/tokio#1708) otherwise this could be released as an alpha whenever (in my opinion, I have nothing further to change).

appveyor.yml Outdated Show resolved Hide resolved
@badboy badboy changed the title Async-ify the API Async-ify the API Dec 30, 2019
@badboy badboy merged commit 0617aba into redis-rs:master Dec 30, 2019
@badboy badboy mentioned this pull request Dec 30, 2019
@dbrgn
Copy link
Contributor

dbrgn commented Dec 30, 2019

Awesome, thanks to everyone involved for landing this feature! 🎉

Marwes pushed a commit to Marwes/redis-rs that referenced this pull request Jan 30, 2020
Regressed in redis-rs#232 (there is a comment explaining what should be done,
only it wasn't anymore)

Fixes redis-rs#275
Marwes pushed a commit to Marwes/redis-rs that referenced this pull request Jan 30, 2020
Regressed in redis-rs#232 (there is a comment explaining what should be done,
only it wasn't anymore)

Fixes redis-rs#275
Marwes pushed a commit to Marwes/redis-rs that referenced this pull request Jan 30, 2020
Regressed in redis-rs#232 (there is a comment explaining what should be done,
only it wasn't anymore)

Fixes redis-rs#275
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants