GH-110829: Ensure Thread.join() joins the OS thread#110848
Conversation
|
@gpshead This should work at least on Linux, hopefully on Windows if I'm lucky. |
ef411ef to
41b9cba
Compare
|
@zooba I think my use of the Windows APIs is correct here, but you might want to take a look. |
| unsigned long long ull_handle = PyLong_AsUnsignedLongLong(handle_obj); | ||
| if ((*ident == (unsigned long) -1 || ull_handle == (unsigned long long) -1) | ||
| && PyErr_Occurred()) { | ||
| // This should not occur as we control the contents of state->joinable_dict | ||
| return -1; | ||
| } | ||
| *handle = (Py_uintptr_t) ull_handle; |
|
|
||
| def test_terminate(self): | ||
| if self.TYPE == 'threads': | ||
| self.skipTest("Threads cannot be terminated") |
There was a problem hiding this comment.
Note the changes in this file are probably not necessary, it's just that without them the threads emulation of processes takes a very long time to test. The reason is simple and not related to this PR: while you can terminate a process early, you cannot do that on a thread, so joining a sleeping thread has to wait for the sleep to finish.
There was a problem hiding this comment.
We can use a shorter wait time rather than skip the test entirely: #114186
| } else { | ||
| PyThread_detach_thread((Py_uintptr_t) handle); | ||
| } | ||
| } |
There was a problem hiding this comment.
We might also want to emit a ResourceWarning here, what do you think @vstinner ?
There was a problem hiding this comment.
Thinking about it, I'd rather defer this to a later PR (if at all).
|
!buildbot wasm |
|
🤖 New build scheduled with the buildbot fleet by @pitrou for commit 26e868c 🤖 The command will test the builders whose names match following regular expression: The builders matched are:
|
|
Most buildbots are green and the few failures look unrelated: |
26e868c to
e2f440f
Compare
|
I formally announce that there are no buildbot failures :-) I realize that this PR lacks some docs for the |
I'll take a look this week, I was on vacation. |
2546653 to
96849d1
Compare
|
In an ironic (and depressing) twist, it seems that even after |
|
doh! I guess I can understand why, the thread won't be executing anymore so join succeeded but the in kernel data structure cleanup will take its own sweet time. :/ I still think it is a valuable addition that we wait for the OS join to happen (thanks for all this work, reviews & merge) but I understand it is annoying given one of the motivating reasons. |
Uh oh!
There was an error while loading. Please reload this page.