id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	os	architecture	failure	difficulty	testcase	blockedby	blocking	related
1399	better support for developing threaded applications in ghci	guest		"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."	feature request	new	normal	_|_	GHCi	6.6.1			claus.reinke@…	Unknown/Multiple	Unknown/Multiple		Unknown