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

chore: prepare Tokio v1.8.4 #4237

Merged
merged 16 commits into from
Nov 16, 2021
Merged

chore: prepare Tokio v1.8.4 #4237

merged 16 commits into from
Nov 16, 2021

Conversation

hawkw
Copy link
Member

@hawkw hawkw commented Nov 16, 2021

1.8.4 (November 15, 2021)

This release backports a bug fix from 1.13.1.

Fixed

Depends on #4226

## Motivation

Currently, the safety invariants and synchronization strategy used in
`tokio::sync::oneshot` are not particularly obvious, especially to a new
reader. It would be nice to better document this code to make these
invariants clearer.

## Solution

This branch adds `SAFETY:` comments to the `oneshot` channel
implementation. In particular, I've focused on documenting the
invariants around when the inner `UnsafeCell` that stores the value can
be accessed by the sender and receiver sides of the channel.

I still want to take a closer look at when the waker cells can be set,
and I'd like to add more documentation there in a follow-up branch.

Signed-off-by: Eliza Weisman <eliza@buoyant.io>
@hawkw hawkw changed the title Eliza/1.8.4 chore: prepare Tokio v1.8.4 Nov 16, 2021
# 1.8.4 (November 15, 2021)

This release backports a bug fix from 1.13.1.

### Fixed

- sync: fix a data race between `oneshot::Sender::send` and awaiting a
  `oneshot::Receiver` when the oneshot has been closed ([#4226])

[#4226]: #4226
@hawkw
Copy link
Member Author

hawkw commented Nov 16, 2021

Ugh, the build's failing because there's other stuff that hasn't been backported to the LTS branch, that's cool.

@hawkw
Copy link
Member Author

hawkw commented Nov 16, 2021

Note that it was also necessary to backport #4186 and #3988 in order to get CI to pass on the v1.8.x branch.

@Noah-Kennedy
Copy link
Contributor

For time audit issue: d4848a9

@hawkw
Copy link
Member Author

hawkw commented Nov 16, 2021

For time audit issue: d4848a9

Thanks for finding that <3

Copy link
Contributor

@Noah-Kennedy Noah-Kennedy 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!

@Noah-Kennedy
Copy link
Contributor

MacOS is broken:

failures:
    try_recv_buf_never_block
    try_send_recv_never_block

@Noah-Kennedy
Copy link
Contributor

FreeBSD is also borked

@Darksonn Darksonn added the A-tokio Area: The main tokio crate label Nov 16, 2021
@Darksonn
Copy link
Contributor

The borked tests were fixed in #3952 on master.

@Noah-Kennedy Noah-Kennedy self-requested a review November 16, 2021 14:35
@hawkw
Copy link
Member Author

hawkw commented Nov 16, 2021

The borked tests were fixed in #3952 on master.

Thanks, I'll grab that commit as well.

@hawkw
Copy link
Member Author

hawkw commented Nov 16, 2021

In order to get the macros build tests to pass I had to basically cherry-pick every tokio-macros change since 1.2.0 and then bless slightly diffferent compiler output for some reason...I don't think this is a problem, because we're not going to release a LTS version of tokio-macros from this branch?

@Darksonn
Copy link
Contributor

The tokio-macros crate has its own tags for its previous releases.

@hawkw hawkw merged commit 2273eb1 into tokio-1.8.x Nov 16, 2021
@hawkw hawkw deleted the eliza/1.8.4 branch November 16, 2021 20:22
hawkw added a commit that referenced this pull request Nov 16, 2021
# 1.8.4 (November 15, 2021)

This release backports a bug fix from 1.13.1.

### Fixed

- sync: fix a data race between `oneshot::Sender::send` and awaiting a
  `oneshot::Receiver` when the oneshot has been closed ([#4226])

[#4226]: #4226
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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants