Idea for handling of async operations for which waiting for the outcome or the outcome itself is irrelevant #1036
paolobarbolini
started this conversation in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I had an idea. I'm still not sure if it's a good approach the library should promote, but I see sometimes async-nats finds itself in this situation, for example inside
Drop
implementations or other code in general 1 2.Here are the assumptions my idea is based on:
tokio::spawn
in order not to block the main application loop, ignoring any errors that might occurtokio::spawn
can be seen as a sort-of unbounded queueasync-nats
calls can be seen as a fancy wrapper around a boundedmpsc
sendermpsc
sender and ignores the outcome?This could be implemented via
IntoFuture
.Instead of having to duplicate all function calls, let's take
publish
as an example. The current function signature is:by changing it into this
we could have
PublishBuilder
implement bothIntoFuture
and thetry_send
method, which would be used like so:The same could be done for a few more methods:
Footnotes
https://github.com/nats-io/nats.rs/blob/08342bb3dcde89f0ed02a08f5c040c8f326caa94/async-nats/src/lib.rs#L1020-L1029 ↩
https://github.com/nats-io/nats.rs/blob/08342bb3dcde89f0ed02a08f5c040c8f326caa94/async-nats/src/jetstream/consumer/push.rs#L130-L135 ↩
Beta Was this translation helpful? Give feedback.
All reactions