net.corda.node.utilities / FiberBox

FiberBox

class FiberBox<out T>

Modelled on ThreadBox, but with support for waiting that is compatible with Quasar Fibers and MutableClocks.

It supports 3 main operations, all of which operate in a similar context to the locked method of ThreadBox. i.e. in the context of the content.

The construct also supports MutableClocks so it can cope with artificial progress towards the deadline, for simulations or testing.

Currently this is intended for use within a node as a simplified way for Oracles to implement subscriptions for changing data by running a protocol internally to implement the request handler (see NodeInterestRates.Oracle), which can then effectively relinquish control until the data becomes available. This isnt the most scalable design and is intended to be temporary. In addition, its enitrely possible to envisage a time when we want public ProtocolLogic implementations to be able to wait for some condition to become true outside of message send/receive. At that point we may revisit this implementation and indeed the whole model for this, when we understand that requirement more fully.

TODO: We should consider using a Semaphore or CountDownLatch here to make it a little easier to understand, but it seems as though the current version of Qasar does not support suspending on either of their implementations.





Constructors

<init> FiberBox(content: T, lock: Lock = ReentrantLock())

Modelled on ThreadBox, but with support for waiting that is compatible with Quasar Fibers and MutableClocks.

Functions

read fun <R> read(body: T.() -> R): R
readWithDeadline fun <R> readWithDeadline(clock: Clock, deadline: Instant, body: T.() -> R): R
write fun <R> write(body: T.() -> R): R