Opened 7 years ago

Last modified 5 years 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@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

Description

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 (7)

comment:1 Changed 7 years ago by igloo

  • Component changed from Compiler to GHCi
  • Milestone set to 6.8

comment:2 Changed 7 years ago by guest

  • Cc Bulat.Ziganshin@… added

comment:3 Changed 7 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 6 years ago by simonmar

  • Milestone changed from 6.8 branch to 6.10 branch

comment:5 Changed 6 years ago by simonmar

  • Architecture changed from Unknown to Unknown/Multiple

comment:6 Changed 6 years ago by simonmar

  • Operating System changed from Unknown to Unknown/Multiple

comment:7 Changed 5 years ago by igloo

  • Milestone changed from 6.10 branch to _|_
Note: See TracTickets for help on using tickets.