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

Fix feedback from libstd PR, part 1 #140

Merged
merged 9 commits into from
Jun 2, 2019

Conversation

faern
Copy link
Collaborator

@faern faern commented May 13, 2019

Here I address some of the fairly low hanging fruit from faern#1

  1. Simplify unlock_bucket_pair. https://github.com/faern/parking_lot/pull/1/files#r283107487
  2. Use impl Trait instead of a bunch of generics around the park/unpark calls. https://github.com/faern/parking_lot/pull/1/files#diff-f0c71d8c95c3701fb57bafd0a8198201R625
  3. Just re-format a comment.
  4. Remove all #[inline(never)]. https://github.com/faern/parking_lot/pull/1/files#diff-936abe3ecea632b68dddc509e87c7c39R142
  5. Create a separate trait for the ThreadParker and UnparkHandle types. So we have a single place to stick the documentation. And to better ensure all implementers have the exact same API. https://github.com/faern/parking_lot/pull/1/files#r283155912

cc @alexcrichton

/// from any other memory address than the one they were located at when they
/// were initialized. As such, it's UB to call any unsafe method on
/// `ThreadParkerT` if the implementing instance has moved since the last
/// call to any of the unsafe methods.
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It's kind of sad how this one implementation spreads unsafe to all platforms and the API in general. If the generic Unix implementation just boxed the mutex/condvar I think it could become safe, right? It might lose some performance, but that can be measured so we have some numbers. If the difference is not too large, maybe it would be sane to make the entire thread parker API safe in this way?

We can probably move more platforms away from the generic Unix parker and to better, more specific parkers. For example, could not Android use the same futex based one as Linux? Is there nothing more modern than pthread mutexes for BSD?

Copy link
Owner

Choose a reason for hiding this comment

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

I believe Android should already be using futexes? It uses the Linux kernel so target_os should be linux, right?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe use Pin to guarantee that self is not moved?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@bjorn3 Do you have an example on how to do that? I don't know a way to express that without introducing a layer of indirection between the code holding the ThreadParker and the actual pthread C structs.

Copy link
Contributor

Choose a reason for hiding this comment

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

Note that there's a lot of UB scenarios with pthread utilities that are beyond movement (that's one of the major reasons for moving to parking_lot!). I suspect that this is is probably going to have to stay unsafe even if we were to box primitives, but it would be good to document all the unsafe guarantees we know of at least that must be upheld.

While it's unfortuante that the unsafe leaks to other platforms it's also sort of the reality of writing portable code. You're often limited by the lowest common denominator.

@faern faern force-pushed the fix-feedback-from-libstd-1 branch 3 times, most recently from 508c842 to 33b1430 Compare May 13, 2019 20:28
}

cfg_if! {
if #[cfg(all(has_sized_atomics, target_os = "linux"))] {
Copy link
Owner

Choose a reason for hiding this comment

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

You might as well add android here as well. Futex should work since Android also uses Linux.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Sure. I'm not able to test this myself, but now it's added.

fn new() -> Self;

/// Prepares the parker. This should be called before adding it to the queue.
unsafe fn prepare_park(&self);
Copy link
Contributor

Choose a reason for hiding this comment

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

Could this and the methods below have expanded documentation as to why they're unsafe? (e.g. what has to be upheld to actually call them safely)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I'll leave most of the requested documentation updates to @Amanieu. So that will likely be done in a separate PR.

@faern faern force-pushed the fix-feedback-from-libstd-1 branch from 14da63e to 3d5a9c3 Compare May 25, 2019 16:26
@faern faern force-pushed the fix-feedback-from-libstd-1 branch from 3d5a9c3 to 6607fd3 Compare May 25, 2019 16:42
@faern
Copy link
Collaborator Author

faern commented May 25, 2019

@Amanieu Fixed the broken stuff. I think this is ready for review/merge now.

@Amanieu
Copy link
Owner

Amanieu commented Jun 2, 2019

Sorry that it took me so long to review this, but it looks mostly fine.

@Amanieu Amanieu merged commit 3a395e1 into Amanieu:master Jun 2, 2019
@faern faern deleted the fix-feedback-from-libstd-1 branch June 4, 2019 19:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants