[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