Issue 36475: PyEval_AcquireLock() and PyEval_AcquireThread() do not handle runtime finalization properly.
Created on 2019-03-29 19:26 by eric.snow, last changed 2022-04-11 14:59 by admin. This issue is now closed.
| Pull Requests | |||
|---|---|---|---|
| URL | Status | Linked | Edit |
| PR 12667 | merged | nanjekyejoannah, 2019-04-02 19:57 | |
| PR 13068 | merged | vstinner, 2019-05-02 19:35 | |
| Messages (7) | |||
|---|---|---|---|
| msg339138 - (view) | Author: Eric Snow (eric.snow) * ![]() |
Date: 2019-03-29 19:26 | |
Daemon threads keep running until they finish or until finalization starts. For the latter, there is a check right after the thread acquires the GIL which causes the thread to exit if runtime finalization has started. [1] However, there are functions in the C-API that facilitate acquiring the GIL, but do not cause the thread to exit during finalization: PyEval_AcquireLock() PyEval_AcquireThread() Daemon threads that acquire the GIL through these can cause a deadlock during finalization. (See issue #36469.) They should probably be updated to match what PyEval_RestoreThread() does. [1] see PyEval_RestoreThread() and the eval loop, in PyEval_EvalFrameEx() |
|||
| msg339365 - (view) | Author: Joannah Nanjekye (nanjekyejoannah) * ![]() |
Date: 2019-04-02 20:12 | |
@eric.snow , you can review the PR I submitted for this. |
|||
| msg339876 - (view) | Author: Joannah Nanjekye (nanjekyejoannah) * ![]() |
Date: 2019-04-10 16:52 | |
@eric do we need any tests for this? |
|||
| msg341054 - (view) | Author: STINNER Victor (vstinner) * ![]() |
Date: 2019-04-29 08:38 | |
New changeset f781d202a2382731b43bade845a58d28a02e9ea1 by Victor Stinner (Joannah Nanjekye) in branch 'master': bpo-36475: Finalize PyEval_AcquireLock() and PyEval_AcquireThread() properly (GH-12667) https://github.com/python/cpython/commit/f781d202a2382731b43bade845a58d28a02e9ea1 |
|||
| msg341055 - (view) | Author: STINNER Victor (vstinner) * ![]() |
Date: 2019-04-29 08:48 | |
I am not comfortable to backport this change to Python 3.7. It's too early to know how it will impact applications and how many complains we will get :-) If someone really wants to backport this scary change to 3.7, I would suggest to wait for 1 month after Python 3.8.0 final release. I close the issue. See bpo-36479 for the follow-up. |
|||
| msg341389 - (view) | Author: STINNER Victor (vstinner) * ![]() |
Date: 2019-05-04 15:48 | |
New changeset c664b342a47e4b4650706d07e3e40a295e3a4407 by Victor Stinner in branch 'master': bpo-36475: Make PyThread_exit_thread with _Py_NO_RETURN (GH-13068) https://github.com/python/cpython/commit/c664b342a47e4b4650706d07e3e40a295e3a4407 |
|||
| msg363714 - (view) | Author: STINNER Victor (vstinner) * ![]() |
Date: 2020-03-09 10:53 | |
I marked bpo-23592 as duplicate of this issue. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022-04-11 14:59:13 | admin | set | github: 80656 |
| 2020-03-09 10:53:27 | vstinner | set | messages: + msg363714 |
| 2020-03-09 10:53:14 | vstinner | link | issue23592 superseder |
| 2019-05-04 15:48:07 | vstinner | set | messages: + msg341389 |
| 2019-05-02 19:35:54 | vstinner | set | pull_requests: + pull_request12985 |
| 2019-04-29 09:23:39 | vstinner | set | status: open -> closed stage: patch review -> resolved resolution: fixed versions: + Python 3.8, - Python 3.6 |
| 2019-04-29 08:48:32 | vstinner | set | messages:
+ msg341055 versions: + Python 3.6, - Python 3.7, Python 3.8 |
| 2019-04-29 08:38:51 | vstinner | set | messages: + msg341054 |
| 2019-04-24 14:08:13 | vstinner | set | nosy:
+ vstinner |
| 2019-04-10 16:52:48 | nanjekyejoannah | set | messages: + msg339876 |
| 2019-04-02 20:12:59 | nanjekyejoannah | set | nosy:
+ nanjekyejoannah messages: + msg339365 |
| 2019-04-02 19:57:32 | nanjekyejoannah | set | keywords:
+ patch stage: test needed -> patch review pull_requests: + pull_request12595 |
| 2019-03-29 19:57:42 | eric.snow | set | components: + Interpreter Core |
| 2019-03-29 19:26:20 | eric.snow | create | |
