Create a Dispatcher that can be used within a resource scope. Once the resource scope exits, depending on the termination policy all active effects will be canceled or awaited, and attempts to submit new effects will throw an exception.

This corresponds to a pattern in which a single Dispatcher is being used by multiple calling threads simultaneously, with complex (potentially long-running) actions submitted for evaluation. In this mode, order of operation is not in any way guaranteed, and execution of each submitted action has some unavoidable overhead due to the forking of a new fiber for each action. This mode is most appropriate for scenarios in which a single Dispatcher is being widely shared across the application, and where sequencing is not assumed.

The lifecycle of spawned fibers is managed by Supervisor. The termination policy can be configured by the await parameter.

Create a Dispatcher that can be used within a resource scope. Once the resource scope exits, all active effects will be canceled, and attempts to submit new effects will throw an exception.

Create a Dispatcher that can be used within a resource scope. Once the resource scope exits, depending on the termination policy all active effects will be canceled or awaited, and attempts to submit new effects will throw an exception.

This corresponds to a Dispatcher mode in which submitted actions are evaluated strictly in sequence (FIFO). In this mode, any actions submitted to Dispatcher.unsafeRunAndForget are guaranteed to run in exactly the order submitted, and subsequent actions will not start evaluation until previous actions are completed. This avoids a significant amount of overhead associated with the Parallel mode and allows callers to make assumptions around ordering, but the downside is that long-running actions will starve subsequent actions, and all submitters must contend for a singular coordination resource. Thus, this mode is most appropriate for cases where the actions are relatively trivial (such as Queue.offer) and the Dispatcher in question is not shared across multiple producers. To be clear, shared dispatchers in sequential mode will still function correctly, but performance will be suboptimal due to single-point contention.

Create a Dispatcher that can be used within a resource scope. Once the resource scope exits, all active effects will be canceled, and attempts to submit new effects will throw an exception.