Table of Contents

Class AsyncMapStatus<TInput, TResult>

Namespace
SodaFlow.Async
Assembly
SodaFlow.Core.Async.dll

The status of a MapAsync pipeline, with the Execute methods. MapAsync answers with this type. A caller that wants only IsRunning and the disposal holds AsyncMapStatus. One that also wants Items holds AsyncMapStatus<TInput>, and one that also wants an Execute method holds this type. Thus, the count of the type parameters a caller keeps says what that caller does with the pipeline.

Execute has one purpose. The operation of a MapAsync pipeline calls a second MapAsync pipeline with it, and waits for the result of that one value. See Execute(TInput).

[PublicAPI]
public sealed class AsyncMapStatus<TInput, TResult> : AsyncMapStatus<TInput>, IDisposable

Type Parameters

TInput

The type of the input values.

TResult

The type of the results.

Inheritance
AsyncMapStatus<TInput, TResult>
Implements
Inherited Members
Extension Methods

Methods

Execute(Cell<TInput>)

Puts the value of a cell into this pipeline and answers with the Task of that value alone. This method reads the cell in the transaction that puts the value in. Thus, the pipeline admits the value that the cell has at that instant. A caller that samples a cell and then calls Execute(TInput) has two transactions, and the value of the cell can change between them. A deferral carries the read with it. The read and the send are thus together in each condition.

This method has the same one purpose as Execute(TInput), and the Task obeys the same rules. Read the remarks of that method.

Execute(TInput)

Puts one value into this pipeline and answers with the Task of that value alone.

This method has one purpose. The operation of a MapAsync pipeline calls a second MapAsync pipeline with it, and waits for the result of that one value. Thus, an operation can be a pipeline of its own, and the strategy of the inner pipeline controls the inner work. An operation is an async method, thus it can await the Task.

Other code does not use this method. Code that has a value for a pipeline sends that value on the source stream of the pipeline, and reads the results stream. That is the interface of a pipeline. It keeps the identity of one value out of code that does not use that identity.

The value goes through the strategy as a value from the source stream does, thus the call obeys the concurrency rules of the pipeline. The result reaches the results stream also, and this method gives the same object.

The Task ends one time, in each condition. It gives the result where the operation gives one and the strategy publishes it. That result is the same object that the results stream gets. It carries the exception where the operation throws and the strategy publishes that, and the errors stream gets the same exception.

These conditions cancel the Task. A cancellation that stops the value cancels it. A strategy that refuses the value cancels it. A strategy that does not publish the outcome cancels it also. Such a strategy says that no code wants the result, which is a cancellation at a different moment. A disposal of the pipeline before the admission of the value cancels it.

One condition gives no end to the Task, and it is not in the position that this method is for. A strategy that keeps a value in the queue permanently, and does not cancel that value, gives no end for the pipeline to read. Each strategy in this library ends each value. The documented method for a strategy to refuse a value cancels that value, thus that method ends the Task.

A transaction that fails cancels the Task. Where a transaction is open, this method defers the value into the post queue of that transaction. A throw while that transaction propagates discards that queue, thus the value never enters the pipeline. This method asks the transaction to cancel the Task in that condition. A throw from the body of a transaction is different. That transaction closes, the queue drains, and the pipeline admits the value.

A call with a transaction open is legal. The code of an operation before its first await runs in the transaction that started that operation. Thus, a caller of this method can have a transaction open. This method defers the value to a transaction of its own in that condition. The pipeline then admits the value after the transaction of the caller ends.