watch::Sender: Modify and send value conditionally #4591

uklotzde · 2022-03-31T09:57:28Z

TODO

Improve documentation

Often times you need to check preconditions and constraints before actually modifying a value. Currently receivers are notified unconditionally, even if the value has not been modified.

This PR adds a function send_if_modified() that is more versatile than send_modify(). The result of the passed closure indicates if the mutably borrowed value has actually been modified or not. Receivers are only notified if the value has been modified as indicated by the sender.

Signed-off-by: Uwe Klotz uwe.klotz@slowtec.de

uklotzde · 2022-03-31T11:16:03Z

Getting the doctest right was trickier than expected. But now it is more restrictive and also considers the changed flag.

Darksonn · 2022-03-31T11:16:15Z

A breaking change in the main Tokio crate is not going to happen.

uklotzde · 2022-03-31T11:17:32Z

What do you suggest? Add a new function send_modified() or send_modify_if()?

Darksonn · 2022-03-31T11:19:40Z

A new function would be possible.

Add a function that is more versatile than send_modify(). The result of the passed closure indicates if the mutably borrowed value has actually been modified or not. Receivers are only notified if the value has been modified as indicated by the sender. Signed-off-by: Uwe Klotz <uwe.klotz@slowtec.de>

uklotzde · 2022-03-31T11:45:39Z

I have added a new function, force pushed, and updated the PR description.

The name of the new function and its parameter have been chosen to be readable and to reflect the expected behavior. Other suggestions are always welcome.

Darksonn · 2022-04-03T09:55:29Z

Someone pointed out that that can already be implemented using watch::Sender::borrow to view the value before sending. Does this not match your use-case?

uklotzde · 2022-04-03T10:09:08Z

Someone pointed out that that can already be implemented using watch::Sender::borrow to view the value before sending. Does this not match your use-case?

How could this work reliably? Upgrading a read lock to a write lock could cause deadlocks. Therefore we need to acquire a write lock right from the start without marking the value as dirty.

Darksonn · 2022-04-03T10:53:27Z

The watch channel is single-producer. With only one sender, there's no race even if you unlock the read lock to take the write lock.

uklotzde · 2022-04-03T11:14:33Z

The watch channel is single-producer. With only one sender, there's no race even if you unlock the read lock to take the write lock.

Doesn't work for my FRP use case where I am sharing the Sender between different independent, async tasks by wrapping it into an Arc. Syntactically this is valid. But with this additional indirection on the sender side the only-notify-if-modfied pattern cannot be implemented safely, because different senders could otherwise deadlock each other.

Or do I need to use a full featured MPMC queue for this purpose?

Darksonn · 2022-04-03T11:16:41Z

I suppose it is true that you can have multiple senders by wrapping it in an Arc.

Avoid using mutable local variables.

Darksonn

Alright, I think this change looks good. It's annoying that we've ended up with so many different send methods, but I suppose it is fine. I do have one comment regarding the docs though.

Darksonn · 2022-04-06T14:42:59Z

tokio/src/sync/watch.rs

+    /// The closure that modifies the value must return `true` if the
+    /// value has actually been modified. It should only return `false`
+    /// if the value is guaranteed to be unnmodified despite the mutable
+    /// borrow. Receivers are only notified if the value has been modified.


Although not modifying it when you return false is the intended use-case, I still think we should document what happens if you modify the value and then return false.

While we are at it: Should we remove the redundancy in the docs and refer to the more versatile send_if_modified() in the docs for send_modify()? The docs would then basically reflect the forwarding of the implementation.

Any improvements to the docs you can come up with would be good! Let me know when you think the docs are ready.

I have revised and aligned the docs of both functions, highlighting their differences and similarities. Since I am not a native speaker someone should verify.

Removing the redundancies would be difficult. Copying the shared parts should be ok to keep the descriptions readable.

uklotzde · 2022-04-06T18:45:29Z

Alright, I think this change looks good. It's annoying that we've ended up with so many different send methods, but I suppose it is fine. I do have one comment regarding the docs though.

Hopefully, this is now the most universal variant. Envisioning all possible use cases right from the start is always difficult.

Capturing intermediate results is possible by storing them in the (mutable) environment of the closure. Therefore I am confident that the boolean result extension is sufficient here.

Aligning the names by renaming it to send_modify_if() could be an option to reflect that the new function is an extension of the existing one. On the other hand send_if_modified() is more fluent to read and better reflects the purpose.

…_send_modified

Add a function that is more versatile than send_modify(). The result of the passed closure indicates if the mutably borrowed value has actually been modified or not. Receivers are only notified if the value has been modified as indicated by the sender. Signed-off-by: Uwe Klotz <uwe.klotz@slowtec.de>

This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [tokio](https://tokio.rs) ([source](https://github.com/tokio-rs/tokio)) | dependencies | minor | `1.18.2` -> `1.19.1` | | [tokio](https://tokio.rs) ([source](https://github.com/tokio-rs/tokio)) | dev-dependencies | minor | `1.18.2` -> `1.19.1` | --- ### Release Notes <details> <summary>tokio-rs/tokio</summary> ### [`v1.19.1`](https://github.com/tokio-rs/tokio/releases/tag/tokio-1.19.1) [Compare Source](tokio-rs/tokio@tokio-1.19.0...tokio-1.19.1) ##### 1.19.1 (June 5, 2022) This release fixes a bug in `Notified::enable`. ([#4747]) [#4747]: tokio-rs/tokio#4747 ### [`v1.19.0`](https://github.com/tokio-rs/tokio/releases/tag/tokio-1.19.0) [Compare Source](tokio-rs/tokio@tokio-1.18.2...tokio-1.19.0) ##### 1.19.0 (June 3, 2022) ##### Added - runtime: add `is_finished` method for `JoinHandle` and `AbortHandle` ([#4709]) - runtime: make global queue and event polling intervals configurable ([#4671]) - sync: add `Notified::enable` ([#4705]) - sync: add `watch::Sender::send_if_modified` ([#4591]) - sync: add resubscribe method to broadcast::Receiver ([#4607]) - net: add `take_error` to `TcpSocket` and `TcpStream` ([#4739]) ##### Changed - io: refactor out usage of Weak in the io handle ([#4656]) ##### Fixed - macros: avoid starvation in `join!` and `try_join!` ([#4624]) ##### Documented - runtime: clarify semantics of tasks outliving `block_on` ([#4729]) - time: fix example for `MissedTickBehavior::Burst` ([#4713]) ##### Unstable - metrics: correctly update atomics in `IoDriverMetrics` ([#4725]) - metrics: fix compilation with unstable, process, and rt, but without net ([#4682]) - task: add `#[track_caller]` to `JoinSet`/`JoinMap` ([#4697]) - task: add `Builder::{spawn_on, spawn_local_on, spawn_blocking_on}` ([#4683]) - task: add `consume_budget` for cooperative scheduling ([#4498]) - task: add `join_set::Builder` for configuring `JoinSet` tasks ([#4687]) - task: update return value of `JoinSet::join_one` ([#4726]) [#4498]: tokio-rs/tokio#4498 [#4591]: tokio-rs/tokio#4591 [#4607]: tokio-rs/tokio#4607 [#4624]: tokio-rs/tokio#4624 [#4656]: tokio-rs/tokio#4656 [#4671]: tokio-rs/tokio#4671 [#4682]: tokio-rs/tokio#4682 [#4683]: tokio-rs/tokio#4683 [#4687]: tokio-rs/tokio#4687 [#4697]: tokio-rs/tokio#4697 [#4705]: tokio-rs/tokio#4705 [#4709]: tokio-rs/tokio#4709 [#4713]: tokio-rs/tokio#4713 [#4725]: tokio-rs/tokio#4725 [#4726]: tokio-rs/tokio#4726 [#4729]: tokio-rs/tokio#4729 [#4739]: tokio-rs/tokio#4739 </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about these updates again. --- - [x] If you want to rebase/retry this PR, click this checkbox. --- This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate). Co-authored-by: cabr2-bot <cabr2.help@gmail.com> Reviewed-on: https://codeberg.org/Calciumdibromid/CaBr2/pulls/1394 Reviewed-by: crapStone <crapstone@noreply.codeberg.org> Co-authored-by: Calciumdibromid Bot <cabr2_bot@noreply.codeberg.org> Co-committed-by: Calciumdibromid Bot <cabr2_bot@noreply.codeberg.org>

github-actions bot added the R-loom Run loom tests on this PR label Mar 31, 2022

uklotzde force-pushed the watch_send_modified branch 4 times, most recently from acd4cdc to 1f3b5a3 Compare March 31, 2022 11:14

Darksonn added A-tokio Area: The main tokio crate M-sync Module: tokio/sync labels Mar 31, 2022

uklotzde force-pushed the watch_send_modified branch from 1f3b5a3 to c713603 Compare March 31, 2022 11:39

uklotzde changed the title ~~watch::Sender: Modify value conditionally~~ watch::Sender: Modify and send value conditionally Mar 31, 2022

watch::Sender Streamline control flow in send_if_modified()

2acc5de

Avoid using mutable local variables.

uklotzde mentioned this pull request Apr 3, 2022

Mutable: Modify values in place Pauan/rust-signals#52

Closed

watch::Sender Improve readability of send_if_modified()

6bd5cc5

uklotzde force-pushed the watch_send_modified branch from 0c360a4 to 6bd5cc5 Compare April 3, 2022 17:16

Darksonn approved these changes Apr 6, 2022

View reviewed changes

uklotzde marked this pull request as draft April 7, 2022 12:50

sync::watch: Improve docs of Sender::send_modify()/send_if_modified()

e577371

uklotzde marked this pull request as ready for review April 7, 2022 13:54

Merge branch 'master' of git@github.com:tokio-rs/tokio.git into watch…

0e53b81

…_send_modified

Merge branch 'master' of git@github.com:tokio-rs/tokio.git into watch…

2269791

…_send_modified

Darksonn enabled auto-merge (squash) May 3, 2022 06:53

Darksonn merged commit c14566e into tokio-rs:master May 3, 2022

uklotzde deleted the watch_send_modified branch May 3, 2022 09:11

Darksonn mentioned this pull request Jun 3, 2022

chore: prepare Tokio v1.19.0 #4738

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

watch::Sender: Modify and send value conditionally #4591

watch::Sender: Modify and send value conditionally #4591

uklotzde commented Mar 31, 2022 •

edited

Loading

uklotzde commented Mar 31, 2022

Darksonn commented Mar 31, 2022

uklotzde commented Mar 31, 2022 •

edited

Loading

Darksonn commented Mar 31, 2022

uklotzde commented Mar 31, 2022

Darksonn commented Apr 3, 2022

uklotzde commented Apr 3, 2022

Darksonn commented Apr 3, 2022

uklotzde commented Apr 3, 2022

Darksonn commented Apr 3, 2022

Darksonn left a comment

Darksonn Apr 6, 2022

uklotzde Apr 6, 2022

Darksonn Apr 7, 2022 •

edited

Loading

uklotzde Apr 7, 2022

uklotzde commented Apr 6, 2022

watch::Sender: Modify and send value conditionally #4591

watch::Sender: Modify and send value conditionally #4591

Conversation

uklotzde commented Mar 31, 2022 • edited Loading

TODO

uklotzde commented Mar 31, 2022

Darksonn commented Mar 31, 2022

uklotzde commented Mar 31, 2022 • edited Loading

Darksonn commented Mar 31, 2022

uklotzde commented Mar 31, 2022

Darksonn commented Apr 3, 2022

uklotzde commented Apr 3, 2022

Darksonn commented Apr 3, 2022

uklotzde commented Apr 3, 2022

Darksonn commented Apr 3, 2022

Darksonn left a comment

Choose a reason for hiding this comment

Darksonn Apr 6, 2022

Choose a reason for hiding this comment

uklotzde Apr 6, 2022

Choose a reason for hiding this comment

Darksonn Apr 7, 2022 • edited Loading

Choose a reason for hiding this comment

uklotzde Apr 7, 2022

Choose a reason for hiding this comment

uklotzde commented Apr 6, 2022

uklotzde commented Mar 31, 2022 •

edited

Loading

uklotzde commented Mar 31, 2022 •

edited

Loading

Darksonn Apr 7, 2022 •

edited

Loading