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

Implement Weak version of mpsc::Sender #4595

Merged
merged 13 commits into from
Jul 27, 2022

Conversation

b-naber
Copy link
Contributor

@b-naber b-naber commented Apr 3, 2022

Attempt to fix #4023

@github-actions github-actions bot added the R-loom Run loom tests on this PR label Apr 3, 2022
@Darksonn Darksonn added A-tokio Area: The main tokio crate M-sync Module: tokio/sync labels Apr 3, 2022
Copy link
Contributor

@Darksonn Darksonn left a comment

Choose a reason for hiding this comment

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

Seems like a relatively simple implementation.

tokio/src/sync/mpsc/chan.rs Outdated Show resolved Hide resolved
tokio/src/sync/mpsc/chan.rs Outdated Show resolved Hide resolved
tokio/src/sync/mpsc/chan.rs Outdated Show resolved Hide resolved
tokio/src/sync/mpsc/chan.rs Outdated Show resolved Hide resolved
@b-naber
Copy link
Contributor Author

b-naber commented Apr 8, 2022

Looks like we can't use loom's Arc version either, since it doesn't have a downgrade assoc function. Is it a problem using std::Arc or shall we add downgrade to loom::Arc? I guess this is blocked on loom having downgrade and a Weak version (I can open a PR for that if we want to do that).

@Darksonn
Copy link
Contributor

I believe that it should be possible to get this work using the normal Arc because we count the number of senders separately in tx_count.

@b-naber
Copy link
Contributor Author

b-naber commented Jun 29, 2022

I think this would require us to manually call decrement_strong_count though on downcast, otherwise the channel would never be dropped, wouldn't it? Which isn't inherently bad, but we would basically manually mirror Weak then afaict. Using Weak seems like the better option, also seems straightforward to add to loom.

@Darksonn
Copy link
Contributor

Well, it's true that this means that the Chan struct may stay alive until all Weak handles are dropped, but its unclear whether that's a problem.

@b-naber
Copy link
Contributor Author

b-naber commented Jun 30, 2022

Ok, I thought that would be a no-go. If that's fine then I'll gladly change the PR.

Probably should mention in the docs for WeakSender, that all outstanding instances need to be dropped for the memory of the underlying channel to be freed, shouldn't we?

@Darksonn
Copy link
Contributor

I mean, that's true for the weak version of Arc too. I think the bigger question is when pending messages are dropped if there are some left in the channel at the end.

@b-naber
Copy link
Contributor Author

b-naber commented Jun 30, 2022

I mean, that's true for the weak version of Arc too.

Is it? I think inner of the Arc is dropped once the strong count reaches 0.

I think the bigger question is when pending messages are dropped if there are some left in the channel at the end.

hm I think they should. When the last (strong) Sender is dropped, we'll put a 'closed' message on the list and any message that is put onto the list after that should be dropped imo. What do you think?

@Darksonn
Copy link
Contributor

Is it? I think inner of the Arc is dropped once the strong count reaches 0.

The value in the Arc is dropped, yes, but the allocation containing it stays around.

hm I think they should. When the last (strong) Sender is dropped, we'll put a 'closed' message on the list and any message that is put onto the list after that should be dropped imo. What do you think?

Messages can't be put on the list after dropping the last sender?

Perhaps you mean that we should drop pending messages when dropping the receiver. I'm happy with doing that.

@b-naber
Copy link
Contributor Author

b-naber commented Jun 30, 2022

Maybe I'm misunderstanding, so just to clarify: The only way for messages to be pending is if they're awaiting being granted a permit or are itself futures that are awaiting, right? And once a permit is given out the message is put onto the list. We now want to forbid those messages, which were pending, to be put onto the list after the Receiver was dropped?

@Darksonn
Copy link
Contributor

Darksonn commented Jul 1, 2022

I believe that we already prevent sending messages after the Receiver is dropped. The question is what happens to those sent before the Receiver was dropped.

let (send, recv) = mpsc::unbounded();
send.send("hello");
drop(recv);
// is "hello" dropped now?

@b-naber b-naber force-pushed the weak-mpsc-sender branch 2 times, most recently from 853399c to 355e4c1 Compare July 6, 2022 17:03
Copy link
Contributor

@Darksonn Darksonn left a comment

Choose a reason for hiding this comment

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

Besides these comments, I think this looks good.

tokio/src/sync/mpsc/chan.rs Outdated Show resolved Hide resolved
tokio-util/tests/mpsc.rs Outdated Show resolved Hide resolved
@b-naber b-naber force-pushed the weak-mpsc-sender branch 2 times, most recently from 36fd514 to 4122c9a Compare July 18, 2022 08:39
tokio-util/tests/mpsc.rs Outdated Show resolved Hide resolved
tokio/tests/sync_mpsc.rs Outdated Show resolved Hide resolved
tokio/tests/sync_mpsc.rs Outdated Show resolved Hide resolved
tokio/tests/sync_mpsc.rs Outdated Show resolved Hide resolved
tokio/src/sync/mpsc/bounded.rs Outdated Show resolved Hide resolved
tokio/src/sync/mpsc/bounded.rs Outdated Show resolved Hide resolved
tokio/src/sync/mpsc/bounded.rs Outdated Show resolved Hide resolved
tokio/src/sync/mpsc/bounded.rs Outdated Show resolved Hide resolved
tokio/src/sync/mpsc/chan.rs Outdated Show resolved Hide resolved
tokio/src/sync/mpsc/bounded.rs Outdated Show resolved Hide resolved
tokio/src/sync/mpsc/bounded.rs Outdated Show resolved Hide resolved
tokio/src/sync/mpsc/bounded.rs Outdated Show resolved Hide resolved
tokio/src/sync/mpsc/chan.rs Outdated Show resolved Hide resolved
tokio/tests/sync_mpsc.rs Outdated Show resolved Hide resolved
tokio/tests/sync_mpsc.rs Outdated Show resolved Hide resolved
tokio/tests/sync_mpsc.rs Outdated Show resolved Hide resolved
@Darksonn
Copy link
Contributor

Please click "resolve" on the things you have fixed.

Copy link
Contributor

@Darksonn Darksonn left a comment

Choose a reason for hiding this comment

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

Looks good to me.

@Darksonn Darksonn merged commit 1d75b57 into tokio-rs:master Jul 27, 2022
@b-naber b-naber deleted the weak-mpsc-sender branch July 27, 2022 14:13
crapStone pushed a commit to Calciumdibromid/CaBr2 that referenced this pull request Sep 11, 2022
This PR contains the following updates:

| Package | Type | Update | Change |
|---|---|---|---|
| [tokio](https://tokio.rs) ([source](https://github.com/tokio-rs/tokio)) | dependencies | minor | `1.20.1` -> `1.21.0` |
| [tokio](https://tokio.rs) ([source](https://github.com/tokio-rs/tokio)) | dev-dependencies | minor | `1.20.1` -> `1.21.0` |

---

### Release Notes

<details>
<summary>tokio-rs/tokio</summary>

### [`v1.21.0`](https://github.com/tokio-rs/tokio/releases/tag/tokio-1.21.0)

[Compare Source](tokio-rs/tokio@tokio-1.20.1...tokio-1.21.0)

##### 1.21.0 (September 2, 2022)

This release is the first release of Tokio to intentionally support WASM. The `sync,macros,io-util,rt,time` features are stabilized on WASM. Additionally the wasm32-wasi target is given unstable support for the `net` feature.

##### Added

-   net: add `device` and `bind_device` methods to TCP/UDP sockets ([#&#8203;4882])
-   net: add `tos` and `set_tos` methods to TCP and UDP sockets ([#&#8203;4877])
-   net: add security flags to named pipe `ServerOptions` ([#&#8203;4845])
-   signal: add more windows signal handlers ([#&#8203;4924])
-   sync: add `mpsc::Sender::max_capacity` method ([#&#8203;4904])
-   sync: implement Weak version of `mpsc::Sender` ([#&#8203;4595])
-   task: add `LocalSet::enter` ([#&#8203;4765])
-   task: stabilize `JoinSet` and `AbortHandle` ([#&#8203;4920])
-   tokio: add `track_caller` to public APIs ([#&#8203;4805], [#&#8203;4848], [#&#8203;4852])
-   wasm: initial support for `wasm32-wasi` target ([#&#8203;4716])

##### Fixed

-   miri: improve miri compatibility by avoiding temporary references in `linked_list::Link` impls ([#&#8203;4841])
-   signal: don't register write interest on signal pipe ([#&#8203;4898])
-   sync: add `#[must_use]` to lock guards ([#&#8203;4886])
-   sync: fix hang when calling `recv` on closed and reopened broadcast channel ([#&#8203;4867])
-   task: propagate attributes on task-locals ([#&#8203;4837])

##### Changed

-   fs: change panic to error in `File::start_seek` ([#&#8203;4897])
-   io: reduce syscalls in `poll_read` ([#&#8203;4840])
-   process: use blocking threadpool for child stdio I/O ([#&#8203;4824])
-   signal: make `SignalKind` methods const ([#&#8203;4956])

##### Internal changes

-   rt: extract `basic_scheduler::Config` ([#&#8203;4935])
-   rt: move I/O driver into `runtime` module ([#&#8203;4942])
-   rt: rename internal scheduler types ([#&#8203;4945])

##### Documented

-   chore: fix typos and grammar ([#&#8203;4858], [#&#8203;4894], [#&#8203;4928])
-   io: fix typo in `AsyncSeekExt::rewind` docs ([#&#8203;4893])
-   net: add documentation to `try_read()` for zero-length buffers ([#&#8203;4937])
-   runtime: remove incorrect panic section for `Builder::worker_threads` ([#&#8203;4849])
-   sync: doc of `watch::Sender::send` improved ([#&#8203;4959])
-   task: add cancel safety docs to `JoinHandle` ([#&#8203;4901])
-   task: expand on cancellation of `spawn_blocking` ([#&#8203;4811])
-   time: clarify that the first tick of `Interval::tick` happens immediately ([#&#8203;4951])

##### Unstable

-   rt: add unstable option to disable the LIFO slot ([#&#8203;4936])
-   task: fix incorrect signature in `Builder::spawn_on` ([#&#8203;4953])
-   task: make `task::Builder::spawn*` methods fallible ([#&#8203;4823])

[#&#8203;4595]: tokio-rs/tokio#4595

[#&#8203;4716]: tokio-rs/tokio#4716

[#&#8203;4765]: tokio-rs/tokio#4765

[#&#8203;4805]: tokio-rs/tokio#4805

[#&#8203;4811]: tokio-rs/tokio#4811

[#&#8203;4823]: tokio-rs/tokio#4823

[#&#8203;4824]: tokio-rs/tokio#4824

[#&#8203;4837]: tokio-rs/tokio#4837

[#&#8203;4840]: tokio-rs/tokio#4840

[#&#8203;4841]: tokio-rs/tokio#4841

[#&#8203;4845]: tokio-rs/tokio#4845

[#&#8203;4848]: tokio-rs/tokio#4848

[#&#8203;4849]: tokio-rs/tokio#4849

[#&#8203;4852]: tokio-rs/tokio#4852

[#&#8203;4858]: tokio-rs/tokio#4858

[#&#8203;4867]: tokio-rs/tokio#4867

[#&#8203;4877]: tokio-rs/tokio#4877

[#&#8203;4882]: tokio-rs/tokio#4882

[#&#8203;4886]: tokio-rs/tokio#4886

[#&#8203;4893]: tokio-rs/tokio#4893

[#&#8203;4894]: tokio-rs/tokio#4894

[#&#8203;4897]: tokio-rs/tokio#4897

[#&#8203;4898]: tokio-rs/tokio#4898

[#&#8203;4901]: tokio-rs/tokio#4901

[#&#8203;4904]: tokio-rs/tokio#4904

[#&#8203;4920]: tokio-rs/tokio#4920

[#&#8203;4924]: tokio-rs/tokio#4924

[#&#8203;4928]: tokio-rs/tokio#4928

[#&#8203;4935]: tokio-rs/tokio#4935

[#&#8203;4936]: tokio-rs/tokio#4936

[#&#8203;4937]: tokio-rs/tokio#4937

[#&#8203;4942]: tokio-rs/tokio#4942

[#&#8203;4945]: tokio-rs/tokio#4945

[#&#8203;4951]: tokio-rs/tokio#4951

[#&#8203;4953]: tokio-rs/tokio#4953

[#&#8203;4956]: tokio-rs/tokio#4956

[#&#8203;4959]: tokio-rs/tokio#4959

</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.

---

 - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, click this checkbox.

---

This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzMi4xODcuMCIsInVwZGF0ZWRJblZlciI6IjMyLjE4Ny4wIn0=-->

Co-authored-by: cabr2-bot <cabr2.help@gmail.com>
Reviewed-on: https://codeberg.org/Calciumdibromid/CaBr2/pulls/1532
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-tokio Area: The main tokio crate M-sync Module: tokio/sync R-loom Run loom tests on this PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Implement a Weak mpsc Sender variant
2 participants