Skip to content

Commit

Permalink
Elaborate about synchronous vs asynchronous executions (#1456)
Browse files Browse the repository at this point in the history
  • Loading branch information
martintmk authored Aug 7, 2023
1 parent e162c57 commit 0047a84
Showing 1 changed file with 8 additions and 0 deletions.
8 changes: 8 additions & 0 deletions src/Polly.Core/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -126,6 +126,14 @@ This way, the responsibility of how to execute method is lifted from the user an

The life of extensibility author is also simplified as they only maintain one implementation of strategy instead of multiple ones. See the duplications in [`Polly.Retry`](https://github.com/App-vNext/Polly/tree/main/src/Polly/Retry).

### About Synchronous and Asynchronous Executions

Polly's core, from version 8, fundamentally focuses on asynchronous executions. However, it also supports synchronous executions, which require minimal effort for authors developing custom resilience strategies. This support is enabled by passing and wrapping the synchronous callback provided by the user into an asynchronous one, which returns a completed `ValueTask` upon completion. This feature allows custom resilience strategies to treat all executions as asynchronous. In cases of synchronous execution, the method simply returns a completed task upon awaiting.

There are scenarios where the resilience strategy necessitates genuine asynchronous work. In such cases, authors might decide to optimize for synchronous executions. For instance, they may use `Thread.Sleep` instead of `Task.Delay`. To facilitate this, Polly exposes the `ResilienceContext.IsSynchronous` property, which authors can leverage. It's worth noting, though, that optimizing for synchronous executions might add significant complexity for the author. As a result, some authors may opt to execute the code asynchronously.

A common scenario that illustrates this is the circuit breaker, which allows for hundreds of concurrent executions. In failure scenarios, only one will trigger the opening of the circuit. If this single execution was synchronous, it would involve some synchronous-over-asynchronous code. This situation occurs because, in the circuit breaker, we wanted to avoid duplicating code for synchronous executions. However, this does not impact the scalability of the Circuit Breaker, since such events are rare and do not execute on the hot path.

### Generic Resilience Strategy

Polly also exposes the sealed `ResilienceStrategy<T>` strategy that is just a simple wrapper over `ResilienceStrategy`. This strategy is used for scenarios when the consumer handles the single result type.
Expand Down

0 comments on commit 0047a84

Please sign in to comment.