Skip to content

threading Thread.join should call the OS join API #110829

Description

@gpshead

Feature or enhancement

Proposal:

threading.Thread.join() only waits for the CPython internals to wash its hands of the underlying thread. It doesn't actually wait for the OS thread itself to exit, which in theory happens rapidly as its final internal code completes quickly - but we have no good wait to determine.

Why finally do this now? Now that we're encouraging people to notice and avoid threading existing when os.fork is called in 3.12, a use case has come up for deterministically knowing when the thread is done at the OS level so that the code can proceed with os.fork.

#110510 could use this in an atfork before fork handler for example.

POSIX has pthread_join, we should be able to expose and use via _thread. Windows presumably has an equivalent concept API.

Has this already been discussed elsewhere?

No response given

Links to previous discussion of this feature:

No response

Linked PRs

Activity

  1. pitrou commented on Oct 13, 2023

    @pitrou
    Member

    On Windows, we start the thread with _beginthreadex, so we should be able to call WaitForSingleObject to ensure that the thread has properly terminated. See second example here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/beginthread-beginthreadex?view=msvc-170#examples

    But, of course, on Windows the entire fork() problem doesn't exist, so it's less of a problem if we don't provide lesser guarantees.

    Note that right now we detach the thread as soon as it is started, so we may want to expose a different internal API that doesn't detach the thread.

  2. added 4 commits that reference this issue on Oct 13, 2023
  3. ericsnowcurrently commented on Oct 25, 2023

    @ericsnowcurrently
    Member

    FWIW, the gap between Python-thread-ends and OS-thread-exits bit me after I added the per-interpreter GIL (PEP 684). We ended up with crash due to that interval (a race in the GIL's drop_gil(), which I fixed in gh-105109. The linked PRs on gh-104341 include a couple other approaches I tried out to solve the race (with extra complexity), and IIRC at least one of them would have (partially?) dealt with closing the above gap.

  4. pitrou commented on Oct 25, 2023

    @pitrou
    Member

    The API added here is only for the threading module, though, because it's quite inflexible (see comments in the .h file).

  5. added 4 commits that reference this issue on Oct 27, 2023
  6. hugovk commented on Nov 9, 2023

    @hugovk
    Member

    Closing as the PR has been merged.

  7. pitrou commented on Nov 9, 2023

    @pitrou
    Member

    Oops, sorry for forgetting to close this issue!

  8. added a commit that references this issue on Feb 11, 2024
  9. added a commit that references this issue on Sep 2, 2024
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

    type-featureA feature request or enhancement

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions