gh-140746: Fix Thread.start() that can hang indefinitely - v2

[YvesDup]

This PR is based on the @ryv-odoo PR. I would have preferred to start from @ryv-odoo's PR branch rather than duplicating his code, but I don't know if that's possible.

Following the @colesbury comment,

I would lean towards changing Thread.start and _start_joinable_thread so that we can do the waiting in C:

       try:
           # Start joinable thread
           _start_joinable_thread(self._bootstrap, handle=self._os_thread_handle,
                                  daemon=self.daemon)
       except Exception:
           with _active_limbo_lock:
               del _limbo[self]
           raise

I think we could add a new states to _os_thread_handle to represent the state when self._started.set() was called and to represent the state when the thread fails before then.

I submit this PR that includes the waiting in C the module and raise a runtime exception when the thread handle state is set to failed. This exception is treated in the Thread.start.

• Issue: Thread.start() can hang indefinitely if the new thread fails (MemoryError) during its initialization #140746

[bkap123]

Left a couple of small comments on semantics.

[bkap123]

This comment should be updated now that there can be a FAILED state. Possibly just replace error with FAILED.

[bkap123]

Suggested change

	// +----- FAILED --------+

[bkap123]

"bootstraped" is misspelled everywhere (should be bootstrapped).

[bkap123]

I think this makes more sense:

Suggested change

	// Notify that the bootstraped is done and failed (e.g. Memory error).
	// Notify that bootstrap is done and failed (e.g. Memory error).

[bkap123]

Maybe add something about the new FAILED state that is managed by the C code?

[bkap123]

Suggested change

	// gh-140746: catch error before thread really start
	// gh-140746: catch error before thread really starts

[ryv-odoo]

Hello @YvesDup ,

Now I understand what you meant in your comment 😄. Sorry I certainly misunderstood your comment at the time.

This version changes the behavior slightly from mine: The serving thread (aka the one who call start() on the new Thread) will crash (raise an exception) because of an error raised from the new Thread.
I am not a huge fan of this change because it means that the serving thread might not recover from it (and I feel that errors from sub thread shouldn't impact the parent Thread). But I don't have a strong opinion about it 🤔

I will apply the comments of @bkap123 in my branch since they mainly target my code.

Have a nice day.

[ryv-odoo]

These assertions aren't not run here, the RuntimeError is raised before.
You should de-indent these lines.