Open pablogsal opened 4 years ago
Unfortunately, the thread experience with pdb is not as good as it could be due to the lack of thread-related commands. In other debuggers like gdb, is common to be able to do some of the following operations:
I think the user experience will improve considerably if we could implement at least these features (and maybe some others that we deem useful).
Displaying all threads is trivial.
Stopping all threads is trivial because of the GIL. When pdb runs in a thread all other threads cannot execute python code. They can execute native code bit there is not much we can do about it.
Switching threads is the interesting one. The easiest way is to set the pdb trace function in the target thread and run until they thread executes python code. This has the following considerations:
For this reason, this method can work only for setting breakpoints on threads, not for 'switching threads'. The breakpoint will work because that's the expected behaviour: the day and the possibility of not hitting it is justified on the nature of the breakpoint.
For switching threads, the best way would be to 'virtually switch threads'. This means that somehow we switch internally to the thread stack but we keep executing on the main thread, we merely switch our internal context.
We may need to think as well how some commands interest when you are in a different thread context. For instance, stepping into something when you are in a different thread is equivalent to setting a breakpoints in the next thread instruction, so this has the same considerations as the breakpoints. We may want to disallow this or to emit some warning in this case.
Another possibility would be accept the reality of the switching delay (so all the other commands work without extra changes) and working to minimize it by setting sys.setswitchinterval() to something ridiculously low and then switching it back to the previous value once we are in the thread that we want. If this is not enough we could sed modify the Gil-adquire code to do something similar to what the Python 2 implementation did when signals arrive that is basically switch constantly between threads until the one that we want runs.
I am +1 on this project :)
I am +1000 on this project!
CC @gaogaotiantian, since we were chatting about this yesterday.
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: ```python assignee = None closed_at = None created_at =
labels = ['library', '3.10']
title = 'Implement thread-related commands in pdb'
updated_at =
user = 'https://github.com/pablogsal'
```
bugs.python.org fields:
```python
activity =
actor = 'cebtenzzre'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation =
creator = 'pablogsal'
dependencies = []
files = []
hgrepos = []
issue_num = 41571
keywords = []
message_count = 5.0
messages = ['375579', '375585', '375587', '375589', '376633']
nosy_count = 5.0
nosy_names = ['bar.harel', 'corona10', 'pablogsal', 'iritkatriel', 'cebtenzzre']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = None
url = 'https://bugs.python.org/issue41571'
versions = ['Python 3.10']
```