Provide the ability to run Eff computations concurrently in multiple threads and communicate between them.

Warning: unless you stick to high level functions from the withAsync family, the Concurrent effect makes it possible to escape the scope of any scoped effect operation. Consider the following:

>>> import qualified Effectful.Reader.Static as R

>>> printAsk msg = liftIO . putStrLn . (msg ++) . (": " ++) =<< R.ask

>>> :{
  runEff . R.runReader "GLOBAL" . runConcurrent $ do
    a <- R.local (const "LOCAL") $ do
      a <- async $ do
        printAsk "child (first)"
        threadDelay 20000
        printAsk "child (second)"
      threadDelay 10000
      printAsk "parent (inside)"
      pure a
    printAsk "parent (outside)"
    wait a
:}
child (first): LOCAL
parent (inside): LOCAL
parent (outside): GLOBAL
child (second): LOCAL

Note that the asynchronous computation doesn't respect the scope of local, i.e. the child thread still behaves like it's inside the local block, even though the parent thread already got out of it.

This is because the value provided by the Reader effect is thread local, i.e. each thread manages its own version of it. For the Reader it is the only reasonable behavior, it wouldn't be very useful if its "read only" value was affected by calls to local from its parent or child threads.

However, the cut isn't so clear if it comes to effects that provide access to a mutable state. That's why statically dispatched State and Writer effects come in two flavors, local and shared:

>>> import qualified Effectful.State.Static.Local as SL
>>> :{
  runEff . SL.execState "Hi" . runConcurrent $ do
    replicateConcurrently_ 3 $ SL.modify (++ "!")
:}
"Hi"

>>> import qualified Effectful.State.Static.Shared as SS
>>> :{
  runEff . SS.execState "Hi" . runConcurrent $ do
    replicateConcurrently_ 3 $ SS.modify (++ "!")
:}
"Hi!!!"

In the first example state updates made concurrently are not reflected in the parent thread because the value is thread local, but in the second example they are, because the value is shared.

Run the Concurrent effect.

A monad supporting atomic memory transactions.

Lifted atomically.

Retry execution of the current memory transaction because it has seen values in TVars which mean that it should not continue (e.g. the TVars represent a shared buffer that is now empty). The implementation may block the thread until one of the TVars that it has read from has been updated. (GHC only)

Compose two alternative STM actions (GHC only).

If the first action completes without retrying then it forms the result of the orElse. Otherwise, if the first action retries, then the second action is tried in its place. If both actions retry then the orElse as a whole retries.

Check that the boolean condition is true and, if not, retry.

In other words, check b = unless b retry.

Since: stm-2.1.1

A variant of throw that can only be used within the STM monad.

Throwing an exception in STM aborts the transaction and propagates the exception. If the exception is caught via catchSTM, only the changes enclosed by the catch are rolled back; changes made outside of catchSTM persist.

If the exception is not caught inside of the STM, it is re-thrown by atomically, and the entire STM is rolled back.

Although throwSTM has a type that is an instance of the type of throw, the two functions are subtly different:

throw e    `seq` x  ===> throw e
throwSTM e `seq` x  ===> x

The first example will cause the exception e to be raised, whereas the second one won't. In fact, throwSTM will only cause an exception to be raised when it is used within the STM monad. The throwSTM variant should be used in preference to throw to raise an exception within the STM monad because it guarantees ordering with respect to other STM operations, whereas throw does not.

Exception handling within STM actions.

catchSTM m f catches any exception thrown by m using throwSTM, using the function f to handle the exception. If an exception is thrown, any changes made by m are rolled back, but changes prior to m persist.

Shared memory locations that support atomic memory transactions.

Lifted newTVarIO.

Lifted readTVarIO.

Create a new TVar holding a value supplied

Return the current value stored in a TVar.

Write the supplied value into a TVar.

Mutate the contents of a TVar. N.B., this version is non-strict.

Since: stm-2.3

Strict version of modifyTVar.

Since: stm-2.3

Swap the contents of a TVar for a new value.

Since: stm-2.3

Lifted registerDelay.

Lifted mkWeakTVar.

A TMVar is a synchronising variable, used for communication between concurrent threads. It can be thought of as a box, which may be empty or full.

Create a TMVar which contains the supplied value.

Create a TMVar which is initially empty.

Lifted newTMVarIO.

Lifted newEmptyTMVarIO.

Return the contents of the TMVar. If the TMVar is currently empty, the transaction will retry. After a takeTMVar, the TMVar is left empty.

Put a value into a TMVar. If the TMVar is currently full, putTMVar will retry.

This is a combination of takeTMVar and putTMVar; ie. it takes the value from the TMVar, puts it back, and also returns it.

A version of readTMVar which does not retry. Instead it returns Nothing if no value is available.

Since: stm-2.3

Swap the contents of a TMVar for a new value.

A version of takeTMVar that does not retry. The tryTakeTMVar function returns Nothing if the TMVar was empty, or Just a if the TMVar was full with contents a. After tryTakeTMVar, the TMVar is left empty.

A version of putTMVar that does not retry. The tryPutTMVar function attempts to put the value a into the TMVar, returning True if it was successful, or False otherwise.

Check whether a given TMVar is empty.

Lifted mkWeakTMVar.

TChan is an abstract type representing an unbounded FIFO channel.

Build and return a new instance of TChan

Lifted newTChanIO.

Create a write-only TChan. More precisely, readTChan will retry even after items have been written to the channel. The only way to read a broadcast channel is to duplicate it with dupTChan.

Consider a server that broadcasts messages to clients:

serve :: TChan Message -> Client -> IO loop
serve broadcastChan client = do
    myChan <- dupTChan broadcastChan
    forever $ do
        message <- readTChan myChan
        send client message

The problem with using newTChan to create the broadcast channel is that if it is only written to and never read, items will pile up in memory. By using newBroadcastTChan to create the broadcast channel, items can be garbage collected after clients have seen them.

Since: stm-2.4

Lifted newBroadcastTChanIO.

Duplicate a TChan: the duplicate channel begins empty, but data written to either channel from then on will be available from both. Hence this creates a kind of broadcast channel, where data written by anyone is seen by everyone else.

Clone a TChan: similar to dupTChan, but the cloned channel starts with the same content available as the original channel.

Since: stm-2.4

Read the next value from the TChan.

A version of readTChan which does not retry. Instead it returns Nothing if no value is available.

Since: stm-2.3

Get the next value from the TChan without removing it, retrying if the channel is empty.

Since: stm-2.3

A version of peekTChan which does not retry. Instead it returns Nothing if no value is available.

Since: stm-2.3

Write a value to a TChan.

Put a data item back onto a channel, where it will be the next item read.

Returns True if the supplied TChan is empty.

TQueue is an abstract type representing an unbounded FIFO channel.

Since: stm-2.4

Build and returns a new instance of TQueue

Lifted newTQueueIO.

Read the next value from the TQueue.

A version of readTQueue which does not retry. Instead it returns Nothing if no value is available.

Get the next value from the TQueue without removing it, retrying if the channel is empty.

A version of peekTQueue which does not retry. Instead it returns Nothing if no value is available.

Efficiently read the entire contents of a TQueue into a list. This function never retries.

Since: stm-2.4.5

Write a value to a TQueue.

Put a data item back onto a channel, where it will be the next item read.

Returns True if the supplied TQueue is empty.

TBQueue is an abstract type representing a bounded FIFO channel.

Since: stm-2.4

Builds and returns a new instance of TBQueue.

Lifted newTBQueueIO.

Read the next value from the TBQueue.

A version of readTBQueue which does not retry. Instead it returns Nothing if no value is available.

Get the next value from the TBQueue without removing it, retrying if the channel is empty.

A version of peekTBQueue which does not retry. Instead it returns Nothing if no value is available.

Efficiently read the entire contents of a TBQueue into a list. This function never retries.

Since: stm-2.4.5

Write a value to a TBQueue; blocks if the queue is full.

Put a data item back onto a channel, where it will be the next item read. Blocks if the queue is full.

Return the length of a TBQueue.

Since: stm-2.5.0.0

Returns True if the supplied TBQueue is empty.

Returns True if the supplied TBQueue is full.

Since: stm-2.4.3