5 ms·

Not a windows user, but the same applies to gdb. What is your proposal? If you're currently debugging a thread, breakpoints are disabled for other threads? That

Not a windows user, but the same applies to gdb. What is your proposal? If you're currently debugging a thread, breakpoints are disabled for other threads? That really doesn't seem like what people would expect by default.

phendrenad2 8y ago
It’s a UX issue, not a behavior issue, I think. What I would do is... after the user presses the “step” button, until the user presses the “continue normally” (or whatever the free run button that ends the debugger is in VS), if breakpoints are encountered in other threads, they are quietly opened in new tabs, places under the current debugger tab. Maybe flash the tab a bit to let the user know this has happened. I don’t think VS has tabs for the debugger interface, so it would need that added.
- neverfone 8y ago
  Hmmph, I see what you're saying, that sounds like it could work. I think the tab flashing is the critical detail, otherwise you would be confused why things are deadlocking.
jamesfmilne 8y ago
GDB can do that already. (gdb) help set scheduler-locking Set mode for locking scheduler during execution. off == no locking (threads may preempt at any time) on == full locking (no thread except the current thread may run) step == scheduler locked during every single-step operation. In this mode, no other thread may run during a step command. Other threads may run while stepping over a function call ('next').
- giancarlostoro 8y ago
  GDB has all sorts of super powers but is there a GUI that works well with GDB?
  - renox 8y ago
    Yes, gdb --tui ;-)
- Arnavion 8y ago
  The VS debugger can freeze threads too. Neither gdb nor VS can help AFAIK if the user doesn't want to freeze the other threads.