Hoogle Search

Within LTS Haskell 24.52 (ghc-9.10.3)

Note that Stackage only displays results for the latest LTS and Nightly snapshot. Learn more.

Exact lookup

1. x8664LinuxGnuReadelf :: ProcessType r => r

   shell-conduit	Data.Conduit.Shell.PATH

   No documentation available.

2. threadId :: Server -> ThreadId

   skews	Network.WebSockets.Skews

   Call killThread to stop the server.

3. postMsgReqThreadTs :: PostMsgReq -> Maybe Text

   slack-web	Web.Slack.Chat

   No documentation available.

4. postMsgThreadTs :: PostMsg -> Maybe Text

   slack-web	Web.Slack.Chat

   No documentation available.

5. groupLastRead :: GroupConversation -> SlackTimestamp

   slack-web	Web.Slack.Conversation

   No documentation available.

6. threadTs :: MessageEvent -> Maybe Text

   slack-web	Web.Slack.Experimental.Events.Types

   Present if the message is in a thread

7. threadTs :: BotMessageEvent -> Maybe Text

   slack-web	Web.Slack.Experimental.Events.Types

   Present if the message is in a thread

8. package slave-thread

   A fundamental solution to ghost threads and silent exceptions Vanilla thread management in Haskell is low level and it does not approach the problems related to thread deaths. When it's used naively the following typical problems arise:

   • When a forked thread dies due to an uncaught exception, the exception does not get raised in the main thread, which is why the program continues to run as if nothing happened, i.e., with the presumption that the already dead thread is running normally. Naturally this may very well bring your program to a chaotic state.
   • Another issue is that one thread dying does not affect any of the threads forked from it. That's why your program may be accumulating ghost threads.
   • Ever dealt with your program ignoring the <Ctrl-C> strikes?
   This library solves all the issues above with a concept of a slave thread. A slave thread has the following properties:
   1. When it dies for whatever reason (exception or finishing normally) it kills all the slave threads that were forked from it. This protects you from ghost threads.
   2. It waits for all slaves to die and execute their finalizers before executing its own finalizer and getting released itself. This gives you hierarchical releasing of resources.
   3. When a slave thread dies with an uncaught exception it reraises it in the master thread. This protects you from silent exceptions and lets you be sure of getting informed if your program gets brought to an erroneous state.

9. module SlaveThread

   Vanilla thread management in Haskell is low level and it does not approach the problems related to thread deaths. When it's used naively the following typical problems arise:

   • When a forked thread dies due to an uncaught exception, the exception does not get raised in the main thread, which is why the program continues to run as if nothing happened, i.e., with the presumption that the already dead thread is running normally. Naturally this may very well bring your program to a chaotic state.
   • Another issue is that one thread dying does not affect any of the threads forked from it. That's why your program may be accumulating ghost threads.
   • Ever dealt with your program ignoring the <Ctrl-C> strikes?
   This library solves all the issues above with a concept of a slave thread. A slave thread has the following properties:
   1. When it dies for whatever reason (exception or finishing normally) it kills all the slave threads that were forked from it. This protects you from ghost threads.
   2. It waits for all slaves to die and execute their finalizers before executing its own finalizer and getting released itself. This gives you hierarchical releasing of resources.
   3. When a slave thread dies with an uncaught exception it reraises it in the master thread. This protects you from silent exceptions and lets you be sure of getting informed if your program gets brought to an erroneous state.

10. data SlaveThreadCrashed

    slave-thread	SlaveThread

    A slave thread crashed. This exception is classified as asynchronous, meaning it extends from SomeAsyncException. In general,

    • Synchronous exceptions such as IOException are thrown by IO actions that are explicitly called by the thread that receives them, and may be caught, inspected, and handled by resuming execution.
    • Asynchronous exceptions such as ThreadKilled should normally only be caught temporarily in order to run finalizers, then re-thrown.
    SlaveThreadCrashed being asynchronous means it should, by default, cause the entire thread hierarchy to come crashing down, ultimately terminating the program. If you want more sophisticated behavior, such as a "supervisor" thread that monitors and restarts worker threads when they fail, you have to program that yourself. N.B. Consider using a library like safe-exceptions or unliftio, which carefully distinguish synchronous and asynchronous exceptions, unlike base.

Page 815 of many | Previous | Next