For a new requirement, and to make the control function of the arbiter more similar to an ELM-like update function, the arbiter needs to be able to cancel moms that are active in its field.
The implementation is split into two parts:
Cancellable Moms
To convert a simple mom into an externally cancellable mom, it may just be wrapped in an Mom.any [ waitFor CancellationEvent; mom ], and as soon the CancellationEvent is received, mom will be cancelled. To avoid conflicts when many of the same cancellable moms are running, the CancellationEvent needs to be unique. To ensure that, unique Ids need to be generated.
Two types of cancellable Moms should be supported. Hard and soft cancellation.
A hard cancellation cancels the mom and leaves it in a Completed Cancelled result.
A soft cancellation returns an explicit value for the cancelled mom. Soft cancellations may be implemented by returning F#'s Result type.
Adding Runtime Features to the Arbiter
In addition to that, the Arbiter needs to be able to schedule events (a feature the runtime itself supports so far only), and although it is a not a direct requirement, it seems that the Arbiter should also be able to react to events, too. So the input to the arbiter (currently 'state and 'r result) will be changed to a sum type similar to the follwing:
type ArbiterMessage<'r> =
| MomCompleted of 'r result
| Event of obj
and the signature changes to 'state -> ArbiterMessage<'r> -> ArbiterDecision<'state, 'r>
and the ArbiterDecision's ContinueField needs an additional tuple argument that defines a list of events that need to be scheduled into the field.
This is a breaking change and the semantics for that are not entirely pinned down yet.
For a new requirement, and to make the control function of the arbiter more similar to an ELM-like update function, the arbiter needs to be able to cancel moms that are active in its field.
The implementation is split into two parts:
Cancellable Moms
To convert a simple mom into an externally cancellable mom, it may just be wrapped in an
Mom.any [ waitFor CancellationEvent; mom ], and as soon theCancellationEventis received,momwill be cancelled. To avoid conflicts when many of the same cancellable moms are running, theCancellationEventneeds to be unique. To ensure that, unique Ids need to be generated.Two types of cancellable Moms should be supported. Hard and soft cancellation.
Completed Cancelledresult.Resulttype.Adding Runtime Features to the Arbiter
In addition to that, the Arbiter needs to be able to schedule events (a feature the runtime itself supports so far only), and although it is a not a direct requirement, it seems that the Arbiter should also be able to react to events, too. So the input to the arbiter (currently
'stateand'r result) will be changed to a sum type similar to the follwing:and the signature changes to
'state -> ArbiterMessage<'r> -> ArbiterDecision<'state, 'r>and the
ArbiterDecision'sContinueFieldneeds an additional tuple argument that defines a list of events that need to be scheduled into the field.This is a breaking change and the semantics for that are not entirely pinned down yet.