Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Mark-Simulacrum (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

Marking as needs-fcp and waiting on libs-api, since this is insta-stable. ACP approval doesn't suffice for new stable guarantees AFAIK.

I think there might also be a soundness problem with these APIs?

From docs:

This function transfers ownership of the underlying pthread_t to the caller. Callers are then the unique owners of the pthread_t and must either detach or join the pthread_t once it’s no longer needed.

AFAICT, the implementation of into_inner drops the Packet, decrementing the running threads, which would make the new API unsound in combination with the existing surface area. So I don't think we can provide safe ownership-consuming functions unless they poison the scope or otherwise provide some facility for ensuring it doesn't treat the thread as ended when it hasn't been.

(Ideally we might want to add a Drop impl -- I think that would prevent moving out of a field like this PR does; and/or make into_inner unsafe).

maybe we can split this trait in two parts, like it is done for windows

We discussed this in today's @rust-lang/libs-api meeting. We agreed that all the impls that call into_inner() should not be provided, for the reason @Mark-Simulacrum raised. The traits that only provide as functions are fine.

That would be a blocker for JoinHandleExt, since it has both functions in one trait. There's no problem providing a different extension trait that only provides as_pthread_t, though.

(If that trait were sealed, we could split it in the standard library. But since it isn't sealed, we'd need a separate extension trait.)

@rustbot author

Reminder, once the PR becomes ready for a review, use @rustbot ready.

@Rosdf any updates on this? thanks