Sorry, something went wrong.
|
I think this is too error prone, for a couple of reasons.
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. 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. |
Sorry, something went wrong.
|
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? |
Sorry, something went wrong.
|
The threading module has setprofile() and settrace() functions. |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
|
@markshannon you ok with this plan?
|
Sorry, something went wrong.
|
@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. |
Sorry, something went wrong.
|
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? |
Sorry, something went wrong.
|
I am ambivalent, but the new parameter sounds good if you prefer it that way. |
Sorry, something went wrong.
|
Ok, I have made a first version of the idea proposed by @markshannon. Please @vstinner @markshannon review again. |
Sorry, something went wrong.
There was a problem hiding this comment.
I suggest all_threads=True rather than running_threads=True: in your implementation, threading.settrace() changes old and new threads, all threads, not only old ("running") threads.
With the PR, we have:
Sorry, something went wrong.
|
@vstinner I'm going to change this PR to follow @markshannon request and make it a separate function in Python instead of a parameter. |
Sorry, something went wrong.
|
@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? |
Sorry, something went wrong.
|
I have updated the APIs to use separate functions. |
Sorry, something went wrong.
|
What would be the API in that case? threading.settrace_all_threads and threading.setprofile_all_threads |
Sorry, something went wrong.
| } | ||
| } | ||
|
|
||
| void |
There was a problem hiding this comment.
It's not great that the function cannot report errors. While not returning -1 on error and pass the exception to the caller, rather than handling it with _PyErr_WriteUnraisableMsg()?
Sorry, something went wrong.
There was a problem hiding this comment.
I am mimicking what we do already in PyEval_SetProfile and to avoid surprises I think we should keep these two as synchronized as possible.
Sorry, something went wrong.
There was a problem hiding this comment.
We cannot fix the API of old functions, but we can avoid past mistakes in newly added functions.
Sorry, something went wrong.
There was a problem hiding this comment.
If you want to ignore exceptions on purpose, please mention it in the function documentation.
Sorry, something went wrong.
There was a problem hiding this comment.
If you want to ignore exceptions on purpose, please mention it in the function documentation.
Yeah, I want to do that because I don't want to stop setting the profile function on other threads if an exception in one fails. Unless you strongly disagree, I will document this.
Sorry, something went wrong.
There was a problem hiding this comment.
Honestly, I don't know if HEAD_LOCK/HEAD_UNLOCK is needed, I'm not sure if the GIL protects us here. The PyThreadState_Next() API is not well documented for thread safety :-(
Sorry, something went wrong.
|
I plan to land this this week or the next one to avoid merge conflicts. @markshannon can you give it a last pass? |
Sorry, something went wrong.
There was a problem hiding this comment.
One minor issue with the docs, otherwise LGTM.
Sorry, something went wrong.
|
Nice enhancement, thanks. |
Sorry, something went wrong.
|
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 |
Sorry, something went wrong.
|
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 |
Sorry, something went wrong.
closes: #93503