| | 379 | |
| | 380 | Unfortunately this story is somewhat complicated, ''c'est la vie''. |
| | 381 | |
| | 382 | To understand what happens it is necessary to know how GHCi evaluates an expression at the command line. When the user types in an expression (as a string) it is parsed, type checked, and compiled, and then run. In `main/GHC.hs` we have the function: |
| | 383 | {{{ |
| | 384 | runStmt :: Session -> String -> IO RunResult |
| | 385 | }}} |
| | 386 | The `Session` argument contains the piles of environmental information which is important to the compiler. The `String` is what the user typed in, and `RunResult` is the answer that you get back if the execution terminates. |
| | 387 | |
| | 388 | Normally what happens is that `runStmt` forks a new thread to handle the evaluation of the expression. It then blocks on an `MVar` and waits for the thread to finish. When the thread finishes it fills in the `MVar`, which wakes up `runStmt`, and it returns a `RunResult`. Ultimately this gets passed back to the GHCi command line. Actually, GHCi is merely a ''client'' of the API, and other clients could also call `runStmt` if they wanted something evaluated. |
| | 389 | |
| | 390 | To make the discussion comprehensible let us distinguish two threads: |
| | 391 | 1. The thread which runs the GHCi prompt. |
| | 392 | 2. The thread which is forked to run an expression. |
| | 393 | |
| | 394 | We'll call the first one the ''GHCi thread'', and the second the ''expression thread''. |
| | 395 | |
| | 396 | In the debugger the process of evaluating an expression is made more intricate. The reason is that if the expression thread hits a breakpoint it will want to return ''early'' to the GHCi thread, so that the user can access the GHCi prompt, issue commands ''etcetera''. |
