better support for developing threaded applications in ghci
The haskell threads model has the appealingly simple property that the main thread determines the lifetime of your program. Once the main thread completes, all other threads are killed.
However this doesn't apply when iteratively developing at the ghci command-line. If, for example, you run main
from the ghci prompt, you regain control of the prompt when your main thread terminates, but any threads spawned by it will keep running. This is particularly irksome if some of them hold onto OS resources (e.g. listening TCP sockets) as you find you can't run your code more than once due to resource issues.
It is possible to solve this problem explicitly by killing all the threads yourself at the end of main
, but that amounts to adding a special ghci
workaround to your code, because you wouldn't need that to compile as a standalone application.
I don't have a specific proposal on the best solution. One would be to alter ghci
's semantics so that after the completion of every interactively entered IO a
action you reap all new threads that have been created. The disadvantage of this would be that it inhibits some interesting kinds of debugging exploring where you deliberately fork some threads from ghci and then communicate with them.
A more general solution would be some kind of :command
to run either with-or-without the reaper-like function as preferred.
Trac metadata
Trac field | Value |
---|---|
Version | 6.6.1 |
Type | FeatureRequest |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | Compiler |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | Unknown |
Architecture | Unknown |