Skip to content

API Docs: thread #29378

Closed
Closed

Description

@steveklabnik

Part of #29329

http://doc.rust-lang.org/std/thread/

Here's what needs to be done to close out this issue:

  • the module docs are written a while ago, and contain some questionableish advice. It's not actually bad, it's just not the way I'd orient all of this. A particularly enthusiastic contributor could toss this out and re-write it from scratch. If the rest of this work gets done, we can close the ticket without doing this, but it would be nice.
  • Builder's docs are... okay. Just very uninspired.
  • JoinHandle doesn't go into enough detail, and should show off, for example, the detach behavior.
  • LocalKey could use some links and general cleanup.
  • Thread has very little and very boring docs.
  • panicking could use some more advice on when to use this.
  • park should have its module documentation inlined here, and cleaned up.
  • park_timeout could use links to park
  • spawn needs a lot more docs generally. It's the main interface to this module!
  • yield_now doesn't explain any of the "why".
  • Result should at least show off the "use std::thread; thread::Result" pattern, like all module-specific Result types.

Activity

  1. added
    E-mentorCall for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.
    on Mar 8, 2017
  2. steveklabnik commented on Mar 8, 2017

    @steveklabnik
    ContributorAuthor

    I am happy to mentor anyone who wants to tackle this issue.

  3. added
    A-docsArea: Documentation for any part of the project, including the compiler, standard library, and tools
    on Mar 10, 2017
  4. added
    E-help-wantedCall for participation: Help is requested to fix this issue.
    E-mediumCall for participation: Medium difficulty. Experience needed to fix: Intermediate.
    and removed on Mar 24, 2017
  5. zimurgh commented on Mar 25, 2017

    @zimurgh

    I would be interested in taking on the documentation improvement of Builder as a starter. I'd take on more, but no need to get ahead of myself.

  6. steveklabnik commented on Mar 25, 2017

    @steveklabnik
    ContributorAuthor

    @OldManMike awesome! Please let me know if you need anything.

  7. added a commit that references this issue on May 3, 2017
  8. rap2hpoutre commented on May 4, 2017

    @rap2hpoutre
    Contributor

    I would like to tackle this issue too and add an example on Result. Feel free to stop me if you are already working on it! (but it seems nobody took it right now)

  9. 69 remaining items

  10. added 3 commits that reference this issue on May 16, 2017
  11. added 5 commits that reference this issue on May 24, 2017
  12. added a commit that references this issue on Jun 2, 2017
  13. added
    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
    on Jul 24, 2017
  14. seanprashad commented on Dec 8, 2017

    @seanprashad

    Hi @steveklabnik! I'd LOVE to help bring this across the finish line but with the last documentation issue for the module docs. I'd greatly appreciate some guidance with where to start if it's possible 🙂

  15. steveklabnik commented on Dec 8, 2017

    @steveklabnik
    ContributorAuthor

    Hey @seanprashad that'd be amazing!

    One option is

    A particularly enthusiastic contributor could toss this out and re-write it from scratch.

    Which would be a bunch of work but might be the way to go.

    Basically, I don't think the docs are organized well; they're kind of just a random collection of thoughts. So I think the first task is, how do we want to organize these docs? Generally, good module docs show an overview of the module conceptually, and then highlight key APIs. Maybe we can start there?

  16. steveklabnik commented on Jan 8, 2019

    @steveklabnik
    ContributorAuthor

    Quoting myself above:

    If the rest of this work gets done, we can close the ticket without doing this, but it would be nice.

    We haven't come up with a good plan for the module docs, and so I'm going to close this ticket. If anyone has specific thoughts about improving them, please open a new ticket with details! Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-docsArea: Documentation for any part of the project, including the compiler, standard library, and toolsC-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCE-help-wantedCall for participation: Help is requested to fix this issue.E-mediumCall for participation: Medium difficulty. Experience needed to fix: Intermediate.E-mentorCall for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.P-mediumMedium priority

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions