GeezerVison

I think this is too error prone, for a couple of reasons.

• The main reason is that this sets the expectation that C-API functions taking PyThreadState can take any thread state.
  However, most C-API functions that take PyThreadState are likely to leave the VM in an invalid state if passed anything other than the current thread state.
• What happens when the thread state belongs to a different sub-interpreter from obj?

To be fair, this isn't just an issue with these functions, but any function that takes a PyThreadState parameter.

#93503 is about adding an API to set tracing/profiling on all threads.
Why not add an API that does that?
void PyEval_SetThreadProfileAllThreads(Py_tracefunc func, PyObject *obj)

Also, I don't like offering operations in the C-API that aren't available in Python. We shouldn't be forcing people to write C.

Why not add an API that does that?

I am fine with that. Do you want me to update this PR or create another one?

Also, I don't like offering operations in the C-API that aren't available in Python. We shouldn't be forcing people to write C.

That ship already sailed. Do mean that you would like to also expose such an API in the Python layer?

The threading module has setprofile() and settrace() functions.

The threading module has setprofile() and settrace() functions.

But those only work for newly created threads as I noted in the issue. They are used only when new threads are bootstrapped. What we are trying to do is to add APIs that affect all current threads.

We also cannot change those for backwards compatibility, but we could place the new APIs in the thread module for Python access.

@markshannon you ok with this plan?

• Changing the proposed C APIs to set the trace/profile functions in all threads.
• Add a python API in the thread module that calls the C API.

@markshannon you ok with this plan?

* Changing the proposed C APIs to set the trace/profile functions in all threads.

* Add a python API in the thread module that calls the C API.

Yes. Sounds good to me.

But those only work for newly created threads as I noted in the issue. They are used only when new threads are bootstrapped. What we are trying to do is to add APIs that affect all current threads.

Would it make sense to add a parameter to these threading functions or to sys functions to apply the new tracing/profiling functions to existing threads?

I am ambivalent, but the new parameter sounds good if you prefer it that way.

Ok, I have made a first version of the idea proposed by @markshannon. Please @vstinner @markshannon review again.

@vstinner I'm going to change this PR to follow @markshannon request and make it a separate function in Python instead of a parameter.

@vstinner I'm going to change this PR to follow @markshannon request and make it a separate function in Python instead of a parameter.

Sure, as you want. What would be the API in that case?

I have updated the APIs to use separate functions.

What would be the API in that case?

threading.settrace_all_threads and threading.setprofile_all_threads

I plan to land this this week or the next one to avoid merge conflicts. @markshannon can you give it a last pass?

Nice enhancement, thanks.

You should document the newly added C API functions to: https://docs.python.org/dev/whatsnew/3.12.html#c-api-changes

You should also document the new threading functions in the same document, in a threading section, near: https://docs.python.org/dev/whatsnew/3.12.html#improved-modules

You should document the newly added C API functions to: docs.python.org/dev/whatsnew/3.12.html#c-api-changes

You should also document the new threading functions in the same document, in a threading section, near: docs.python.org/dev/whatsnew/3.12.html#improved-modules

#96681