Tasty Test Results

Tests
- UnliftIO.MessageBox.Util.CallId
  Even when a CallId CounterVar is shared by multiple threads/processes, all callIds are unique (0.01s)
  The next callId is greater and not equal to the previous
  more recent CallIds are > (greater than) all previous CallIds
  +++ OK, passed 100 tests; 8 discarded.
  CallId Show instance
  CallId Laws
  +++ OK, passed 100 tests; 99 discarded.
- CatchAll
  Derived Classes Coverage
  +++ OK, passed 100 tests; 119 discarded.
  when the wrapped receive throws an exception, CatchAlls receive returns Nothing
  when the wrapped tryReceive throws an exception, CatchAlls tryReceive returns a Future that will always return Nothing
  when the wrapped receiveAfter throws an exception, CatchAlls receiveAfter should return Nothing
  when the wrapped deliver throws an exception, CatchAlls deliver returns False
- CornerCaseTests
  waiting for messages from a dead process
  When using the UnlimitedMessageBox, receive will timeout (3.02s)
  When using the Limited Message BlockingBox, the test will timeout (3.02s)
  When using the Limited Waiting Box, the test will timeout (3.03s)
  When using the Limited NonBlocking Box, the test will timeout (3.03s)
  sending messages to a dead process
  When using the UnlimitedMessageBox, sending messages succeeds (0.02s)
  When using the BlockingBoxLimit, sending messages eventually blocks and times out (2.02s)
  When using the NonBlockingBoxLimit, sending messages eventually returns False (0.11s)
  When using the WaitingBoxLimit Nothing, sending messages eventually blocks and times out (0.10s)
  Command
  waiting for a call reply after the server died
  When using the UnlimitedMessageBox, BlockingCommandTimedOut is returned (0.10s)
  When using the BlockingBoxLimit, BlockingCommandTimedOut is returned (0.10s)
  When using the NonBlockingBoxLimit, BlockingCommandTimedOut is returned (0.10s)
  When using WaitingBoxLimit Nothing, BlockingCommandTimedOut is returned (0.10s)
- UnliftIO.MessageBox.Command
  unit tests
  Message Show instance
  CommandError Show instance
  when deliver returns False, BlockingCommandFailed should be returned
  when deliver blocks forever, call also blocks forever regardles of the timeout parameter (0.01s)
  when deliver succeeds, but the reply box is ignored and no replyTo invokation is done, BlockingCommandTimedOut should be returned (0.01s)
  when the reply box is passed to a new process, but replyTo is delayed very much, BlockingCommandTimedOut should be returned (0.01s)
  when the reply box is passed to a new process, that calls replyTo after x seconds, where x < rt (the receive timeou), then before y seconds have passed, where x <= y < rt, call returns the value passed to the reply box. (0.02s)
  when a call is delegated to, and replied by, another process, call should return that reply
  when deliver has a delay, callAsync has at least the same delay (0.09s)
  when deliver fails, callAsync returns Nothing
  when deliver succeeds, callAsync returns Just the pending reply
  when deliver succeeds, but no reply is sent, waitForReply returns Left BlockingCommandTimedOut
  when deliver succeeds, but no reply is sent, tryTakeReply will return Nothing
  when deliver succeeds, and a reply is sent, waitForReply will return Right with the reply
  when deliver has succeeded, and a reply has been sent, tryTakeReply will eventually return Just Right the reply (0.01s)
  after waitForReply returns Right the reply, any further call to waitForReply will return the same result immediately.
  when waitForReply has returned, tryTakeReply will also return Just the same result
  when tryTakeReply has returned Just a result, waitForReply will also return that same result
  DuplicateReply Eq and Show instance
  when replyTo is called again on the same replyBox, an error is thrown and the waitForResult will still return the first reply
  tryTakeReply should return Nothing until the reply is sent, and from the moment the reply is available, it will always and immediately return the reply, it will never return Nothing again
  PendingResult's show instance contains the call Id and the name of the result type
  integration tests
  Show instance of the Message data family works (1.00s)
  all books that many donors concurrently donate into the book store end up in the bookstore (0.03s)
  +++ OK, passed 100 tests.
  handling a cast succeeds
  handling a call succeeds
  reply to dead caller does not crash
  call to died thread returns Nothing (2.00s)
  replying to call within the given timeout is successful
  when the server sends a reply after the call timeout has elapsed, the call function returns 'Left BlockingCommandTimedOut', and the replyTo function returns False (0.50s)
  when the server receives the call and does not send a reply and immediately exits, the call function returns a timeout error (0.10s)
- UnliftIO.MessageBox.Class
  Utilities
  when receive returns Nothing, then handleMessage does not execute the callback and returns Nothing
  when receive returns Just x, then handleMessage applies the callback to x and returns Just the result
  Unlimited
  Basics
  deliver and receive
  tryReceive from an empty queue, without any writer threads
  when a process delivers a message into an input successfully, and then calls receiveAfter, the message is returned
  when receiveAfter is called, and two different messages are delivered late but not too late, then the first message is returned (0.01s)
  when one process delivers a message into an input successfully, while another process calls receive, the message is returned
  when one process delivers two messages into an input successfully, while another process calls receive twice, the messages are returned in FIFO order
  all 113 messages of all 237 outBoxes are received by the messageBox (21.95s)
  tryReceive
  when one process delivers one messages into an input successfully, while another process calls tryReceive, then the future returns the message, and a second tryReceives returns a future that returns Nothing
  when one process delivers one messages into an input successfully, while another process calls tryReceive, then the future returns the message, and a second tryReceives returns a future that returns Nothing, then a second message is deliverd, and the second future returns that value,and the first future still returns the first value(immediately).
  when one process delivers two messages (with random delays) into an input successfully, while another process calls tryReceive twice, then the futures each return the correct message in FIFO order (0.04s)
  CatchAllArg Unlimited
  Basics
  deliver and receive
  tryReceive from an empty queue, without any writer threads
  when a process delivers a message into an input successfully, and then calls receiveAfter, the message is returned
  when receiveAfter is called, and two different messages are delivered late but not too late, then the first message is returned (0.01s)
  when one process delivers a message into an input successfully, while another process calls receive, the message is returned
  when one process delivers two messages into an input successfully, while another process calls receive twice, the messages are returned in FIFO order
  all 113 messages of all 237 outBoxes are received by the messageBox (26.61s)
  tryReceive
  when one process delivers one messages into an input successfully, while another process calls tryReceive, then the future returns the message, and a second tryReceives returns a future that returns Nothing
  when one process delivers one messages into an input successfully, while another process calls tryReceive, then the future returns the message, and a second tryReceives returns a future that returns Nothing, then a second message is deliverd, and the second future returns that value,and the first future still returns the first value(immediately).
  when one process delivers two messages (with random delays) into an input successfully, while another process calls tryReceive twice, then the futures each return the correct message in FIFO order (0.04s)
  Blocking256
  Basics
  deliver and receive
  tryReceive from an empty queue, without any writer threads
  when a process delivers a message into an input successfully, and then calls receiveAfter, the message is returned
  when receiveAfter is called, and two different messages are delivered late but not too late, then the first message is returned (0.01s)
  when one process delivers a message into an input successfully, while another process calls receive, the message is returned
  when one process delivers two messages into an input successfully, while another process calls receive twice, the messages are returned in FIFO order
  all 113 messages of all 237 outBoxes are received by the messageBox (27.76s)
  tryReceive
  when one process delivers one messages into an input successfully, while another process calls tryReceive, then the future returns the message, and a second tryReceives returns a future that returns Nothing
  when one process delivers one messages into an input successfully, while another process calls tryReceive, then the future returns the message, and a second tryReceives returns a future that returns Nothing, then a second message is deliverd, and the second future returns that value,and the first future still returns the first value(immediately).
  when one process delivers two messages (with random delays) into an input successfully, while another process calls tryReceive twice, then the futures each return the correct message in FIFO order (0.04s)
  CatchAllArg Blocking256
  Basics
  deliver and receive
  tryReceive from an empty queue, without any writer threads
  when a process delivers a message into an input successfully, and then calls receiveAfter, the message is returned
  when receiveAfter is called, and two different messages are delivered late but not too late, then the first message is returned (0.01s)
  when one process delivers a message into an input successfully, while another process calls receive, the message is returned
  when one process delivers two messages into an input successfully, while another process calls receive twice, the messages are returned in FIFO order
  all 113 messages of all 237 outBoxes are received by the messageBox (27.75s)
  tryReceive
  when one process delivers one messages into an input successfully, while another process calls tryReceive, then the future returns the message, and a second tryReceives returns a future that returns Nothing
  when one process delivers one messages into an input successfully, while another process calls tryReceive, then the future returns the message, and a second tryReceives returns a future that returns Nothing, then a second message is deliverd, and the second future returns that value,and the first future still returns the first value(immediately).
  when one process delivers two messages (with random delays) into an input successfully, while another process calls tryReceive twice, then the futures each return the correct message in FIFO order (0.04s)
  Blocking1
  Basics
  deliver and receive
  tryReceive from an empty queue, without any writer threads
  when a process delivers a message into an input successfully, and then calls receiveAfter, the message is returned
  when receiveAfter is called, and two different messages are delivered late but not too late, then the first message is returned (0.01s)
  when one process delivers a message into an input successfully, while another process calls receive, the message is returned
  when one process delivers two messages into an input successfully, while another process calls receive twice, the messages are returned in FIFO order
  all 113 messages of all 237 outBoxes are received by the messageBox (12.23s)
  tryReceive
  when one process delivers one messages into an input successfully, while another process calls tryReceive, then the future returns the message, and a second tryReceives returns a future that returns Nothing
  when one process delivers one messages into an input successfully, while another process calls tryReceive, then the future returns the message, and a second tryReceives returns a future that returns Nothing, then a second message is deliverd, and the second future returns that value,and the first future still returns the first value(immediately).
  when one process delivers two messages (with random delays) into an input successfully, while another process calls tryReceive twice, then the futures each return the correct message in FIFO order
  Blocking2
  Basics
  deliver and receive
  tryReceive from an empty queue, without any writer threads
  when a process delivers a message into an input successfully, and then calls receiveAfter, the message is returned
  when receiveAfter is called, and two different messages are delivered late but not too late, then the first message is returned (0.01s)
  when one process delivers a message into an input successfully, while another process calls receive, the message is returned
  when one process delivers two messages into an input successfully, while another process calls receive twice, the messages are returned in FIFO order
  all 113 messages of all 237 outBoxes are received by the messageBox (15.30s)
  tryReceive
  when one process delivers one messages into an input successfully, while another process calls tryReceive, then the future returns the message, and a second tryReceives returns a future that returns Nothing
  when one process delivers one messages into an input successfully, while another process calls tryReceive, then the future returns the message, and a second tryReceives returns a future that returns Nothing, then a second message is deliverd, and the second future returns that value,and the first future still returns the first value(immediately).
  when one process delivers two messages (with random delays) into an input successfully, while another process calls tryReceive twice, then the futures each return the correct message in FIFO order (0.04s)
  NonBlocking1
  Basics
  deliver and receive
  tryReceive from an empty queue, without any writer threads
  when a process delivers a message into an input successfully, and then calls receiveAfter, the message is returned
  when receiveAfter is called, and two different messages are delivered late but not too late, then the first message is returned (0.01s)
  when one process delivers a message into an input successfully, while another process calls receive, the message is returned
  when one process delivers two messages into an input successfully, while another process calls receive twice, the messages are returned in FIFO order
  all 113 messages of all 237 outBoxes are received by the messageBox (30.89s)
  tryReceive
  when one process delivers one messages into an input successfully, while another process calls tryReceive, then the future returns the message, and a second tryReceives returns a future that returns Nothing
  when one process delivers one messages into an input successfully, while another process calls tryReceive, then the future returns the message, and a second tryReceives returns a future that returns Nothing, then a second message is deliverd, and the second future returns that value,and the first future still returns the first value(immediately).
  when one process delivers two messages (with random delays) into an input successfully, while another process calls tryReceive twice, then the futures each return the correct message in FIFO order
  NonBlocking64
  Basics
  deliver and receive
  tryReceive from an empty queue, without any writer threads
  when a process delivers a message into an input successfully, and then calls receiveAfter, the message is returned
  when receiveAfter is called, and two different messages are delivered late but not too late, then the first message is returned (0.01s)
  when one process delivers a message into an input successfully, while another process calls receive, the message is returned
  when one process delivers two messages into an input successfully, while another process calls receive twice, the messages are returned in FIFO order
  all 113 messages of all 237 outBoxes are received by the messageBox (31.50s)
  tryReceive
  when one process delivers one messages into an input successfully, while another process calls tryReceive, then the future returns the message, and a second tryReceives returns a future that returns Nothing
  when one process delivers one messages into an input successfully, while another process calls tryReceive, then the future returns the message, and a second tryReceives returns a future that returns Nothing, then a second message is deliverd, and the second future returns that value,and the first future still returns the first value(immediately).
  when one process delivers two messages (with random delays) into an input successfully, while another process calls tryReceive twice, then the futures each return the correct message in FIFO order (0.04s)
  Waiting_60000000_1
  Basics
  deliver and receive
  tryReceive from an empty queue, without any writer threads
  when a process delivers a message into an input successfully, and then calls receiveAfter, the message is returned
  when receiveAfter is called, and two different messages are delivered late but not too late, then the first message is returned (0.01s)
  when one process delivers a message into an input successfully, while another process calls receive, the message is returned
  when one process delivers two messages into an input successfully, while another process calls receive twice, the messages are returned in FIFO order
  all 113 messages of all 237 outBoxes are received by the messageBox (11.79s)
  tryReceive
  when one process delivers one messages into an input successfully, while another process calls tryReceive, then the future returns the message, and a second tryReceives returns a future that returns Nothing
  when one process delivers one messages into an input successfully, while another process calls tryReceive, then the future returns the message, and a second tryReceives returns a future that returns Nothing, then a second message is deliverd, and the second future returns that value,and the first future still returns the first value(immediately).
  when one process delivers two messages (with random delays) into an input successfully, while another process calls tryReceive twice, then the futures each return the correct message in FIFO order
  Waiting_60000000_64
  Basics
  deliver and receive
  tryReceive from an empty queue, without any writer threads
  when a process delivers a message into an input successfully, and then calls receiveAfter, the message is returned
  when receiveAfter is called, and two different messages are delivered late but not too late, then the first message is returned (0.01s)
  when one process delivers a message into an input successfully, while another process calls receive, the message is returned
  when one process delivers two messages into an input successfully, while another process calls receive twice, the messages are returned in FIFO order
  all 113 messages of all 237 outBoxes are received by the messageBox (27.30s)
  tryReceive
  when one process delivers one messages into an input successfully, while another process calls tryReceive, then the future returns the message, and a second tryReceives returns a future that returns Nothing
  when one process delivers one messages into an input successfully, while another process calls tryReceive, then the future returns the message, and a second tryReceives returns a future that returns Nothing, then a second message is deliverd, and the second future returns that value,and the first future still returns the first value(immediately).
  when one process delivers two messages (with random delays) into an input successfully, while another process calls tryReceive twice, then the futures each return the correct message in FIFO order (0.04s)
  Waiting_60000000_60000000_64
  Basics
  deliver and receive
  tryReceive from an empty queue, without any writer threads
  when a process delivers a message into an input successfully, and then calls receiveAfter, the message is returned
  when receiveAfter is called, and two different messages are delivered late but not too late, then the first message is returned (0.01s)
  when one process delivers a message into an input successfully, while another process calls receive, the message is returned
  when one process delivers two messages into an input successfully, while another process calls receive twice, the messages are returned in FIFO order
  all 113 messages of all 237 outBoxes are received by the messageBox (27.35s)
  tryReceive
  when one process delivers one messages into an input successfully, while another process calls tryReceive, then the future returns the message, and a second tryReceives returns a future that returns Nothing
  when one process delivers one messages into an input successfully, while another process calls tryReceive, then the future returns the message, and a second tryReceives returns a future that returns Nothing, then a second message is deliverd, and the second future returns that value,and the first future still returns the first value(immediately).
  when one process delivers two messages (with random delays) into an input successfully, while another process calls tryReceive twice, then the futures each return the correct message in FIFO order (0.04s)
- UnliftIO.MessageBox.Limited
  BlockingBox
  receive on an empty queue blocks forever (0.10s)
  tryReceive from an empty queue returns future that returns Nothing
  when a message box is full, deliver will block forever (1.00s)
  when sending faster than receiving all messages must be received (5.52s)
  +++ OK, passed 20 tests.
  WaitingBox
  when the receive timeout is Nothing receive blocks forever (0.10s)
  when the receive timeout is Just x, receive returns Nothing after x micro seconds
  when the receive timeout is Just x, and another thread waits 2*x and delivers a message, receive returns Nothing (0.30s)
  when the receive timeout is Just 150_000, and another thread waits 1000 and delivers a message, receive returns Just that message
  tryReceive from an empty queue returns a future that returns Nothing
  when a message box is full, deliver return False after the timeout elapsed
  when sending faster than receiving and when the timeout is sufficiently large, all messages must be received (5.52s)
  +++ OK, passed 20 tests.
  When the message limit is 2, two messages can be enqueued
  when writing into a full box, deliver returns False after the timeout
  receive with/without timeout
  when a receive timeout is Just t, and no message is delivered, receive returns Nothing after the timeout
  when a receive timeout is Nothing, and no message is delivered, receive never returns (0.10s)
  NonBlockingBox
  only delivery is non-blocking, when a message box has no inputs then receive blocks forever (0.10s)
  when writing into a full Input deliver returns False
  when using a limit smaller than half of the number of messsages in the test, deliver first succeeds and then fails (0.40s)
  when sending 5 times faster then receiving, then deliver will begin to fail after some time (0.72s)
  Common Functionality for Blocking64 Note: Tests may vary the limit
  when createBox is applied to a limit > 0, then limit messages can be enqueued
  +++ OK, passed 100 tests; 60 discarded.
  when the message box is 'full' not more then one more messages can be enqueued (10.16s)
  +++ OK, passed 100 tests.
  When the message limit is 2, two messages can be enqueued
  when writing into an empty Input, True is returned
  when writing into a full Input deliver returns False or blocks forever (0.10s)
  when messages are send until the limit is reached,and when x, x < limit messages are received, then x more messages can be delivered again, and all messages are in FIFO order (0.02s)
  +++ OK, passed 20 tests; 1 discarded.
  lock contention robustness
  when many concurrent senders send many messages to one receiver, and when every failed deliver is retried indefinitely, all messages will be received (2.15s)
  Common Functionality for NonBlocking64 Note: Tests may vary the limit
  when createBox is applied to a limit > 0, then limit messages can be enqueued
  +++ OK, passed 100 tests; 55 discarded.
  when the message box is 'full' not more then one more messages can be enqueued (0.24s)
  +++ OK, passed 100 tests.
  When the message limit is 2, two messages can be enqueued
  when writing into an empty Input, True is returned
  when writing into a full Input deliver returns False or blocks forever
  when messages are send until the limit is reached,and when x, x < limit messages are received, then x more messages can be delivered again, and all messages are in FIFO order (0.03s)
  +++ OK, passed 20 tests; 4 discarded.
  lock contention robustness
  when many concurrent senders send many messages to one receiver, and when every failed deliver is retried indefinitely, all messages will be received (2.20s)
  Common Functionality for Waiting_5000000_64 Note: Tests may vary the limit
  when createBox is applied to a limit > 0, then limit messages can be enqueued
  +++ OK, passed 100 tests; 62 discarded.
  when the message box is 'full' not more then one more messages can be enqueued (10.20s)
  +++ OK, passed 100 tests.
  When the message limit is 2, two messages can be enqueued
  when writing into an empty Input, True is returned
  when writing into a full Input deliver returns False or blocks forever (0.10s)
  when messages are send until the limit is reached,and when x, x < limit messages are received, then x more messages can be delivered again, and all messages are in FIFO order (0.05s)
  +++ OK, passed 20 tests; 1 discarded.
  lock contention robustness
  when many concurrent senders send many messages to one receiver, and when every failed deliver is retried indefinitely, all messages will be received (2.22s)
  Common Functionality for Waiting_172800000000_5000000_64 Note: Tests may vary the limit
  when createBox is applied to a limit > 0, then limit messages can be enqueued
  +++ OK, passed 100 tests; 53 discarded.
  when the message box is 'full' not more then one more messages can be enqueued (10.24s)
  +++ OK, passed 100 tests.
  When the message limit is 2, two messages can be enqueued
  when writing into an empty Input, True is returned
  when writing into a full Input deliver returns False or blocks forever (0.10s)
  when messages are send until the limit is reached,and when x, x < limit messages are received, then x more messages can be delivered again, and all messages are in FIFO order (0.04s)
  +++ OK, passed 20 tests; 4 discarded.
  lock contention robustness
  when many concurrent senders send many messages to one receiver, and when every failed deliver is retried indefinitely, all messages will be received (2.23s)
  Derived instances
  MessageLimit code coverage
  +++ OK, passed 100 tests.
  MessageLimit code coverage
  +++ OK, passed 100 tests; 110 discarded.
  BlockingBoxLimit code coverage
  +++ OK, passed 100 tests; 118 discarded.
  NonBlockingBoxLimit code coverage
  +++ OK, passed 100 tests; 126 discarded.
  WaitingBoxLimit code coverage
  +++ OK, passed 100 tests; 117 discarded.
- UnliftIO.MessageBox.Unlimited
  lock contention robustness
  when many concurrent senders send many messages to one receiver, and when every failed deliver is retried indefinitely, all messages will be received (2.14s)
- Protocols.Fresh

Tasty Test Results

Tests

UnliftIO.MessageBox.Util.CallId

Even when a CallId CounterVar is shared by multiple threads/processes, all callIds are unique (0.01s)

The next callId is greater and not equal to the previous

more recent CallIds are > (greater than) all previous CallIds

CallId Show instance

CallId Laws

CatchAll

Derived Classes Coverage

when the wrapped receive throws an exception, CatchAlls receive returns Nothing

when the wrapped tryReceive throws an exception, CatchAlls tryReceive returns a Future that will always return Nothing

when the wrapped receiveAfter throws an exception, CatchAlls receiveAfter should return Nothing

when the wrapped deliver throws an exception, CatchAlls deliver returns False

CornerCaseTests

waiting for messages from a dead process

When using the UnlimitedMessageBox, receive will timeout (3.02s)

When using the Limited Message BlockingBox, the test will timeout (3.02s)

When using the Limited Waiting Box, the test will timeout (3.03s)

When using the Limited NonBlocking Box, the test will timeout (3.03s)

sending messages to a dead process

When using the UnlimitedMessageBox, sending messages succeeds (0.02s)

When using the BlockingBoxLimit, sending messages eventually blocks and times out (2.02s)

When using the NonBlockingBoxLimit, sending messages eventually returns False (0.11s)

When using the WaitingBoxLimit Nothing, sending messages eventually blocks and times out (0.10s)

Command

waiting for a call reply after the server died

When using the UnlimitedMessageBox, BlockingCommandTimedOut is returned (0.10s)

When using the BlockingBoxLimit, BlockingCommandTimedOut is returned (0.10s)

When using the NonBlockingBoxLimit, BlockingCommandTimedOut is returned (0.10s)

When using WaitingBoxLimit Nothing, BlockingCommandTimedOut is returned (0.10s)

UnliftIO.MessageBox.Command

unit tests

Message Show instance

CommandError Show instance

when deliver returns False, BlockingCommandFailed should be returned

when deliver blocks forever, call also blocks forever regardles of the timeout parameter (0.01s)

when deliver succeeds, but the reply box is ignored and no replyTo invokation is done, BlockingCommandTimedOut should be returned (0.01s)

when the reply box is passed to a new process, but replyTo is delayed very much, BlockingCommandTimedOut should be returned (0.01s)

when the reply box is passed to a new process, that calls replyTo after x seconds, where x < rt (the receive timeou), then before y seconds have passed, where x <= y < rt, call returns the value passed to the reply box. (0.02s)

when a call is delegated to, and replied by, another process, call should return that reply

when deliver has a delay, callAsync has at least the same delay (0.09s)

when deliver fails, callAsync returns Nothing

when deliver succeeds, callAsync returns Just the pending reply

when deliver succeeds, but no reply is sent, waitForReply returns Left BlockingCommandTimedOut

when deliver succeeds, but no reply is sent, tryTakeReply will return Nothing

when deliver succeeds, and a reply is sent, waitForReply will return Right with the reply

when deliver has succeeded, and a reply has been sent, tryTakeReply will eventually return Just Right the reply (0.01s)

after waitForReply returns Right the reply, any further call to waitForReply will return the same result immediately.

when waitForReply has returned, tryTakeReply will also return Just the same result

when tryTakeReply has returned Just a result, waitForReply will also return that same result

DuplicateReply Eq and Show instance

when replyTo is called again on the same replyBox, an error is thrown and the waitForResult will still return the first reply

tryTakeReply should return Nothing until the reply is sent, and from the moment the reply is available, it will always and immediately return the reply, it will never return Nothing again

PendingResult's show instance contains the call Id and the name of the result type

integration tests

Show instance of the Message data family works (1.00s)

all books that many donors concurrently donate into the book store end up in the bookstore (0.03s)

handling a cast succeeds

handling a call succeeds

reply to dead caller does not crash

call to died thread returns Nothing (2.00s)

replying to call within the given timeout is successful

when the server sends a reply after the call timeout has elapsed, the call function returns 'Left BlockingCommandTimedOut', and the replyTo function returns False (0.50s)

when the server receives the call and does not send a reply and immediately exits, the call function returns a timeout error (0.10s)

UnliftIO.MessageBox.Class

Utilities

when receive returns Nothing, then handleMessage does not execute the callback and returns Nothing

when receive returns Just x, then handleMessage applies the callback to x and returns Just the result

Unlimited

Basics

deliver and receive

tryReceive from an empty queue, without any writer threads

when a process delivers a message into an input successfully, and then calls receiveAfter, the message is returned

when receiveAfter is called, and two different messages are delivered late but not too late, then the first message is returned (0.01s)

when one process delivers a message into an input successfully, while another process calls receive, the message is returned

when one process delivers two messages into an input successfully, while another process calls receive twice, the messages are returned in FIFO order

all 113 messages of all 237 outBoxes are received by the messageBox (21.95s)

tryReceive

when one process delivers one messages into an input successfully, while another process calls tryReceive, then the future returns the message, and a second tryReceives returns a future that returns Nothing