Opened 11 years ago

Last modified 15 months ago

#1399 new feature request

better support for developing threaded applications in ghci

Reported by: guest Owned by:
Priority: normal Milestone:
Component: GHCi Version: 6.6.1
Keywords: Cc: claus.reinke@…, Bulat.Ziganshin@…, mentheta
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


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.

Change History (8)

comment:1 Changed 11 years ago by igloo

Component: CompilerGHCi
Milestone: 6.8

comment:2 Changed 11 years ago by guest

Cc: Bulat.Ziganshin@… added

comment:3 Changed 11 years ago by claus

Cc: claus.reinke@… added; Bulat.Ziganshin@… removed

a more standard approach would be to add a shell-jobs-like interface for ghci (i.e., ':jobs' or ':get-thread-ids \ids->..' as a way to get a list of all running threads, for further treatment using the existing thread interfaces). then one could write a reaper, or other code analysing the current thread structure for debugging purposes.

comment:4 Changed 11 years ago by simonmar

Milestone: 6.8 branch6.10 branch

comment:5 Changed 10 years ago by simonmar

Architecture: UnknownUnknown/Multiple

comment:6 Changed 10 years ago by simonmar

Operating System: UnknownUnknown/Multiple

comment:7 Changed 10 years ago by igloo

Milestone: 6.10 branch_|_

comment:8 Changed 15 months ago by mentheta

Cc: claus.reinke@… Bulat.Ziganshin@… mentheta added; claus.reinke@… removed
Type of failure: None/Unknown
Note: See TracTickets for help on using tickets.