GeezerVison is showing github.com — threading Thread.join should call the OS join API · Issue #110829 · python/cpython
threading Thread.join should call the OS join API #110829DescriptionFeature 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
Reacted by Antoine Pitrou and sunmy2019 Reacted by Łukasz Langa Activitypitrou commented on Oct 13, 2023 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. ericsnowcurrently commented on Oct 25, 2023 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. pitrou commented on Oct 25, 2023 The API added here is only for the threading module, though, because it's quite inflexible (see comments in the .h file). hugovk commented on Nov 9, 2023 Closing as the PR has been merged. pitrou commented on Nov 9, 2023 Oops, sorry for forgetting to close this issue! Reacted by Hugo van Kemenade
MetadataMetadataStatusShow more project fields
DevelopmentNo branches or pull requestsIssue actions
|