STM package:TCache
A monad supporting atomic memory transactions.
A version in the STM monad
push an element at the top of the queue
Assures that the IO computation finalizes no matter if the STM
transaction is aborted or retried. The IO computation run in a
different thread. The STM transaction wait until the completion of the
IO procedure (or retry as usual).
It can be retried if the embedding STM computation is retried so the
IO computation must be idempotent. Exceptions are bubbled up to the
STM transaction
Unsafely performs IO in the STM monad. Beware: this is a highly
dangerous thing to do.
- The STM implementation will often run transactions multiple times,
so you need to be prepared for this if your IO has any side
effects.
- The STM implementation will abort transactions that are known to
be invalid and need to be restarted. This may happen in the middle of
unsafeIOToSTM, so make sure you don't acquire any resources
that need releasing (exception handlers are ignored when aborting the
transaction). That includes doing any IO using Handles, for example.
Getting this wrong will probably lead to random deadlocks.
- The transaction may have seen an inconsistent view of memory when
the IO runs. Invariants that you expect to be true throughout your
program may not be true inside a transaction, due to the way
transactions are implemented. Normally this wouldn't be visible to the
programmer, but using unsafeIOToSTM can expose it.
This is the main function for the *Resource(s) calls. All the rest
derive from it. The results are kept in the STM monad so it can be
part of a larger STM transaction involving other DBRefs. The
Resources register returned by the user-defined function is
interpreted as such:
- toAdd: the content of this field will be added/updated to
the cache
- toDelete: the content of this field will be removed from
the cache and from permanent storage
- toReturn: the content of this field will be returned by
withSTMResources
WARNING: To catch evaluations errors at the right place, the values to
be written must be fully evaluated. Errors in delayed evaluations at
serialization time can cause inconsistencies in the database.