thread_PyThread_start_new_thread fails with a generic error

[kristjanvalur]

BPO	16003
Nosy	@pitrou, @kristjanvalur, @ZackerySpytz
PRs	gh-60207: Raise OSError instead of ThreadError if thread creation fails #22068

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2012-09-23.08:34:05.959>
labels = ['type-feature']
title = 'thread_PyThread_start_new_thread fails with a generic error'
updated_at = <Date 2020-09-02.16:54:01.695>
user = 'https://github.com/kristjanvalur'

bugs.python.org fields:

activity = <Date 2020-09-02.16:54:01.695>
actor = 'ZackerySpytz'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = []
creation = <Date 2012-09-23.08:34:05.959>
creator = 'kristjan.jonsson'
dependencies = []
files = []
hgrepos = []
issue_num = 16003
keywords = ['patch']
message_count = 2.0
messages = ['171017', '171045']
nosy_count = 3.0
nosy_names = ['pitrou', 'kristjan.jonsson', 'ZackerySpytz']
pr_nums = ['22068']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue16003'
versions = ['Python 3.4']

[kristjanvalur]

If thread creation fails, for any reason, a ThreadError is returned with the error "can't start new thread".
No attempt is made to diagnose the issue.
In fact, for example, if we are out of resources, pthread_new() would have returned EAGAIN. This should perhaps rather be classified as an OSError so that users can catch this and diagnose it. ThreadError seems to be used otherwise exclusively to indicate problems with locking.

Can this be turned into an informative OSError, or is it to platform dependant for any sensible structured error handlng to be implemented?

[pitrou]

I'm personally ok with using a more informative error than ThreadError.