[GHC] #1399: better support for developing threaded applications in
ghci
GHC
trac at galois.com
Thu May 31 10:03:24 EDT 2007
#1399: better support for developing threaded applications in ghci
------------------------------+---------------------------------------------
Reporter: guest | Owner:
Type: feature request | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 6.6.1
Severity: normal | Keywords:
Difficulty: Unknown | Os: Unknown
Testcase: | Architecture: Unknown
------------------------------+---------------------------------------------
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.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1399>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
-------------- next part --------------
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs at haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
More information about the Glasgow-haskell-bugs
mailing list