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

Expose Semaphore::close #3065

Merged
merged 5 commits into from
Dec 15, 2020
Merged

Conversation

zaharidichev
Copy link
Contributor

Motivation

The need to expose Semaphore::close as explained in #3061.

Solution

Expose Semaphore::close

@Darksonn Darksonn added A-tokio Area: The main tokio crate C-enhancement Category: A PR with an enhancement or bugfix. M-sync Module: tokio/sync labels Oct 28, 2020
@carllerche
Copy link
Member

I believe that @darkson is correct. In order to expose close(), we would need to change acquire() to return Result.

If we want to make this change, we would need to make it in 1.0 as it is breaking.

@zaharidichev
Copy link
Contributor Author

That makes sense. Should I close that for the time being then?

@carllerche carllerche added this to the v1.0 milestone Nov 10, 2020
@carllerche
Copy link
Member

I assigned this to the 1.0 milestone. We can leave it open for now.

@taiki-e taiki-e added the S-blocked Status: marked as blocked ❌ on something else such as a PR or other implementation work. label Nov 20, 2020
@taiki-e
Copy link
Member

taiki-e commented Dec 10, 2020

triage: this is no longer blocked

@taiki-e taiki-e removed the S-blocked Status: marked as blocked ❌ on something else such as a PR or other implementation work. label Dec 10, 2020
@LucioFranco
Copy link
Member

@carllerche @Darksonn can we get this reviewed? I don't have much context

@LucioFranco
Copy link
Member

or figure out how to move forward here.

@hawkw
Copy link
Member

hawkw commented Dec 10, 2020

@carllerche @Darksonn can we get this reviewed? I don't have much context

I'll take a look.

@Darksonn
Copy link
Contributor

To move forward this needs to have the acquire methods return a result in case the semaphore has been closed. Or an alternative error-handling should be proposed.

Copy link
Member

@hawkw hawkw left a comment

Choose a reason for hiding this comment

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

As @Darksonn pointed out in https://github.com/tokio-rs/tokio/pull/3065/files#r513557608, the Semaphore::acquire and Semaphore::acquire_owned methods currently unwrap the inner semaphore's result --- this will panic if we close the semaphore:

/// Acquires permit from the semaphore.
pub async fn acquire(&self) -> SemaphorePermit<'_> {
self.ll_sem.acquire(1).await.unwrap();
SemaphorePermit {
sem: &self,
permits: 1,
}
}

These need to be changed to also return Result, like

    /// Acquires permit from the semaphore.
    pub async fn acquire(&self) -> Result<SemaphorePermit<'_>, AcquireError> {
        self.ll_sem.acquire(1).await?;
        Ok(SemaphorePermit {
            sem: &self,
            permits: 1,
        })
    }

We'll also need to add a public error type for indicating that the semaphore is closed (could be a re-export of batch_semaphore::AcquireError). Similarly, we should update TryAcquireError to distinguish between cases where no permits are available and cases where the semaphore is closed (again, this could be a re-export of the inner batch_semaphore error type). Finally, we will want to add to the docs to explain the errors returned by these methods.

Then, I think this should be good to merge. Thanks!

@carllerche
Copy link
Member

@zaharidichev we branched off 1.0. Are you able to complete this PR? Thanks!

@zaharidichev
Copy link
Contributor Author

@carllerche Yes, I am able. Does it need to happen today?

@carllerche
Copy link
Member

Not today. This week is fine!

Signed-off-by: Zahari Dichev <[email protected]>
Signed-off-by: Zahari Dichev <[email protected]>
Signed-off-by: Zahari Dichev <[email protected]>
Closed,

/// The has no available permits.
Copy link
Contributor

Choose a reason for hiding this comment

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

The semaphore

Copy link
Member

@hawkw hawkw left a comment

Choose a reason for hiding this comment

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

Overall, the change looks correct to me! I had some docs suggestions that it would be nice to address before merging — and let's also address Carl's comment about adding a usage example to Semaphore::close.

@@ -41,15 +41,21 @@ struct Waitlist {
closed: bool,
}

/// Error returned by `Semaphore::try_acquire`.
/// Error returned from the `Semaphore::try_acquire` function.
Copy link
Member

Choose a reason for hiding this comment

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

This probably ought to be a link?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@hawkw Correct me if I am wrong, but it seems we cannot link to non public methods. Having this type be located in batch_semaphore and linking to the method in semaphore seems a bit odd. Am I missing something?

Copy link
Member

Choose a reason for hiding this comment

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

The type is exposed in the public API. Users will only ever see it via the public Semaphore type's methods; they shouldn't need to be aware of batch_semaphore, which is an implementation detail. I think it's correct for this to link to the public methods for readers of the documentation.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Makes sense. Thank you !

Closed,

/// The has no available permits.
NoPermits,
}
/// Error returned by `Semaphore::acquire`.
Copy link
Member

Choose a reason for hiding this comment

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

and this one?

@@ -96,21 +88,21 @@ impl Semaphore {
}

/// Acquires permit from the semaphore.
Copy link
Member

Choose a reason for hiding this comment

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

It might be nice if this comment said something about errors, like

Suggested change
/// Acquires permit from the semaphore.
/// Acquires a permit from the semaphore.
///
/// If the semaphore has been closed, this returns an [`AcquireError`].
/// Otherwise, this returns a [`SemaphorePermit`] representing the
/// acquired permit.

or something?

sem: &self,
permits: 1,
}
})
}

/// Acquires `n` permits from the semaphore
Copy link
Member

Choose a reason for hiding this comment

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

and maybe this should say something like

Suggested change
/// Acquires `n` permits from the semaphore
/// Acquires `n` permits from the semaphore.
///
/// If the semaphore has been closed, this returns an [`AcquireError`].
/// Otherwise, this returns a [`SemaphorePermit`] representing the
/// acquired permits.

tokio/src/sync/semaphore.rs Show resolved Hide resolved
tokio/src/sync/semaphore.rs Outdated Show resolved Hide resolved
#[derive(Debug)]
pub(crate) enum TryAcquireError {
pub enum TryAcquireError {
/// The semaphore has been closed and cannot issue new permits
Copy link
Member

Choose a reason for hiding this comment

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

Might be worth linking to the Semaphore::close method here?

Suggested change
/// The semaphore has been closed and cannot issue new permits
/// The semaphore has been [closed] and cannot issue new permits.
///
/// [closed]: crate::sync::Semaphore::close

NoPermits,
}
/// Error returned by `Semaphore::acquire`.
///
/// An `acquire` operation can only fail if the semaphore has been
/// closed.
Copy link
Member

Choose a reason for hiding this comment

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

might be worth linking to the close method here too?

Suggested change
/// closed.
/// [closed].
///
/// [closed]: crate::sync::Semaphore::close

@carllerche
Copy link
Member

@zaharidichev Thanks for updating the PR. I have no additional feedback. Once @hawkw's comments are addressed, I'm fine w/ merging this 👍.

Signed-off-by: Zahari Dichev <[email protected]>
@zaharidichev
Copy link
Contributor Author

I added some additional docs to other methods as well.

Copy link
Member

@hawkw hawkw left a comment

Choose a reason for hiding this comment

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

Okay, the docs look great, thanks for adding examples. I'm going to merge this.

Thanks again for working on this, @zaharidichev!

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 C-enhancement Category: A PR with an enhancement or bugfix. M-sync Module: tokio/sync
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants