This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Thread primitives do not report the OS-level error on failure
Type: behavior Stage:
Components: Library (Lib) Versions: Python 3.8, Python 3.7, Python 3.6, Python 3.4, Python 3.5, Python 2.7
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: drydenb, nitishch, zwol
Priority: normal Keywords:

Created on 2018-01-07 15:50 by zwol, last changed 2022-04-11 14:58 by admin.

Messages (1)
msg309623 - (view) Author: Zack Weinberg (zwol) * Date: 2018-01-07 15:50
[_]thread.start_new_thread can fail if the underlying OS primitive fails (pthread_create / _beginthreadex), but the exception that is thrown when this happens is a generic RuntimeError (it's _called_ ThreadError in the source code, but it doesn't have its own subtype, so you can't even catch it specifically) and the OS-level error code is lost.  It should instead throw (an appropriate subclass of) OSError and capture the error code, like when other OS primitives fail.

Reading through the code, it looks like _all_ of the threading code has this problem - throughout [_]threadmodule.c, thread.c, and thread_pthread.h, I see error codes being dropped on the floor or at best reported with perror or dprintf, not properly captured in an OSError.

This affects all maintained versions of Python, but sadly I expect it's messy enough to fix that it's only practical to do so on trunk.
History
Date User Action Args
2022-04-11 14:58:56adminsetgithub: 76692
2018-01-08 03:48:55nitishchsetnosy: + nitishch
2018-01-08 00:03:35drydenbsetnosy: + drydenb
2018-01-07 15:50:08zwolcreate