-
Notifications
You must be signed in to change notification settings - Fork 252
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
feat: oneshot channel returns Pkid
#806
Conversation
Pkid
Pull Request Test Coverage Report for Build 8478057404Details
💛 - Coveralls |
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 like the idea and also tried it out, with both sync & async, and it works nicely!
Here is my feedback:
- we should avoid placing the
pkid_tx
directly in packets, mqttbytes should strictly be related to protocol parsing. We can maybe put it in request likeRequest::Publish(tx, publish)
? - just
Pkid
seems intuitive thanPkidPromise
- users don't need to know about the oneshot channel, thus instead of just type alias, we should impl / rename some methods. e.g. async client is fine, but when in sync, using
pkid.blocking_recv()
isn't. maybe we can rename that recv to something else? - if we fail to send the pkid from state, maybe we can log some debug lvl info? not sure how often we will fail though.
- examples can be simplified, we just want to show how user can get pkid. So we can simply
await
right after gettingPkid
. Using joinsets / delay queues in unnecessarily adding complexity. Also, users want to associate the publish with the pkid right? awaiting em later via joinset or something will be same as checking forOutgoing
event. - as you suggested in RFC, having many open oneshot channels might addup perf impact which we are unsure of as of now. Whether to feature gate this or not is your call ( as you would know better haha )
It doesn't seem to have much of an impact on perf, I believe it is safe to ignore for now. Cost of feature gating is expensive on the code readability front.
Not really, I got the idea from the user comment in the RFC, it's just to give users an idea of what is possible, they can choose to not go the route we illustrate, but we can try and educate them about the possibilities.
This should be fine, the only reason we couldn't send was because of rx drop, which means the user doesn't want to do anything with the pkid.
From a user perspective, you wouldn't want them to confuse between the awaiting and the occupied state.
✅ |
rumqttc/src/v5/state.rs
Outdated
@@ -183,21 +186,21 @@ impl MqttState { | |||
/// be put on to the network by the eventloop | |||
pub fn handle_outgoing_packet(&mut self, request: Request) -> Result<(), StateError> { | |||
match request { | |||
Request::Publish(publish) => { | |||
Request::Publish(tx, publish) => { | |||
self.check_size(publish.size())?; |
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.
EventLoop
drops the pkid_tx
here if size is not valid
I have a few comments about the
We should probably handle this in a separate PR, I believe the current PR is a good to merge now. |
my thinking was, the examples should show them how they can get the pkid in general. for simple examples sake, getting pkid one by one should be fine imo ( in async & in sync ) we can make separate examples tailored toward why they might want to use joinset ( or something else ). There we should also explain why it is used and when they should and shouldn't use it.
I didn't get this completely, but i would like to differ. Adding |
That's because the receiver is a generic term for receiving data, here we are adding context that we are promising deliver of a |
Fixes #349, implements #805
Type of change
New feature (non-breaking change which adds functionality)
Allows user access to pkid information once it is assigned by rumqttc internals during run.
Checklist:
cargo fmt
CHANGELOG.md
if it's relevant to the users of the library. If it's not relevant mention why.Tests performed
Ran this against provided example async code, output looks as follows
Thus the implementation is complete.