Admin message

Due to a large amount of spam we do not allow new users to create repositories, they are "external" users. If you are a new user and want to create a repository, for example for forking GHC, open a new issue on ghc/ghc using the "get-verified" issue template

Feature request: Allocation limit hooks
<!-- READ THIS FIRST: If the feature you are proposing changes the language that GHC accepts or adds any warnings to `-Wall`, it should be written as a [GHC Proposal](https://github.com/ghc-proposals/ghc-proposals/). Other features, appropriate for a GitLab feature request, include GHC API/plugin innovations, new low-impact compiler flags, or other similar additions to GHC. --> ## Motivation ### GHC's [allocation limit](https://hackage.haskell.org/package/base-4.17.0.0/docs/System-Mem.html#g:2) functionality allows killing a thread that exceeds a pre-set limit of allocations. This is useful, for example, for managing "elephant" queries, see: <http://simonmar.github.io/posts/2017-01-24-asynchronous-exceptions.html>. A limitation of this feature is that it only allows killing a thread when the limit is exceeded. In some situations we do not want to kill a heavily allocating thread, but would rather want to merely log that it is allocating too much. As far as I can tell we don't have facilities to enable this at the moment. ## Proposal I propose we expand the allocation limit functionality by adding a configurable hook to handle what happens in the event of the limit being exceeded. I'm not sure if this hook should be global or local to the thread. Both are fine for my use case. Making it local to the thread would cost extra (we'd add an extra pointer to each TSO), but would be more versatile. The default hook would be to throw an async exception as we do currently. ---- This will probably need a CLC proposal, but I thought I'd make a ticket here first to get some initial feedback
issue