Changes between Version 20 and Version 21 of GhciDebugger


Ignore:
Timestamp:
Feb 20, 2007 2:05:01 PM (7 years ago)
Author:
bjpop
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GhciDebugger

    v20 v21  
    261261The instrumentation is done at the desugarer too, which has been extended accordingly. We distinguish between 'auto' breakpoints, those introduced by the desugarer, and 'normal' breakpoints user created by using the `breakpoint` function directly. 
    262262 
    263 = Breakpoints and threads = 
    264  
    265 In a multi-threaded program breakpoints and threads must be handled carefully. Consider the case that one running thread hits a breakpoint and then another running thread also hits a breakpoint. What should happen? 
    266  
    267 One important note is that when a breakpoint is hit control returns to a GHCi prompt, which has a command line on a terminal. Obviously this prompt is not designed to be run concurrently. So, in the very least, there should only be on thread allowed to enter the debugging prompt at any one time. One mechansim to support this would be to lock entry into the debugger prompt with an MVar. Any other thread which hits a breakpoint will then have to wait on the MVar before proceeding to the prompt. Another more substantial option is to have the schedular stop all running threads whenever a breakpoint is entered. This would allow more features in the debugger, such as the ability to inspect the stacks of running threads and so forth. It also seems to be consistent with the way that gdb works and the java debugger, see [http://sourceware.org/gdb/current/onlinedocs/gdb_6.html#SEC45].  
    268263 
    269264== Overhead == 
     
    350345 
    351346= Pending work = 
     347 
    352348Call stack traces. 
    353349 
     
    368364 
    369365The '''debugger''' itself, i.e. the user interface offered by InteractiveUI, should virtually maintain itself once it is bug-free (which I don't claim it is), as long as future changes to ghci itself respect the few things it assumes. 
     366 
     367=== Breakpoints and threads === 
     368 
     369In a multi-threaded program breakpoints and threads must be handled carefully. Consider the case that one running thread hits a breakpoint and then another running thread also hits a breakpoint. What should happen? 
     370 
     371One important note is that when a breakpoint is hit control returns to a GHCi prompt, which has a command line on a terminal. Obviously this prompt is not designed to be run concurrently. So, in the very least, there should only be on thread allowed to enter the debugging prompt at any one time. One mechansim to support this would be to lock entry into the debugger prompt with an MVar. Any other thread which hits a breakpoint will then have to wait on the MVar before proceeding to the prompt. Another more substantial option is to have the schedular stop all running threads whenever a breakpoint is entered. This would allow more features in the debugger, such as the ability to inspect the stacks of running threads and so forth. It also seems to be consistent with the way that gdb works and the java debugger, see [http://sourceware.org/gdb/current/onlinedocs/gdb_6.html#SEC45].