std.concurrency

Thrown on calls to receiveOnly if a message other than the type the receiving thread expected is sent.

Thrown on calls to receive if the thread that spawned the receiving thread has terminated and no more messages exist.

Thrown if a linked thread has terminated.

Thrown if a message was sent to a thread via

for a message of this type.

Thrown on mailbox crowding if the mailbox is configured with OnCrowding.throwException.

Thrown when a Tid is missing, e.g. when ownerTid doesn't find an owner thread.

An opaque type used to represent a logical thread.

These behaviors may be specified when a mailbox is full.

Encapsulates all implementation-level data needed for scheduling.

When defining a Scheduler, an instance of this struct must be associated with each logical thread. It contains all implementation-level information needed by the internal API.

A Scheduler controls how threading is performed by spawn.

Implementing a Scheduler allows the concurrency mechanism used by this module to be customized according to different needs. By default, a call to spawn will create a new kernel thread that executes the supplied routine and terminates when finished. But it is possible to create Schedulers that reuse threads, that multiplex Fibers (coroutines) across a single thread, or any number of other approaches. By making the choice of Scheduler a user-level option, std.concurrency may be used for far more types of application than if this behavior were predefined.

Example:

import std.concurrency;
import std.stdio;

void main()
{
   scheduler = new FiberScheduler;
   scheduler.start(
   {
       writeln("the rest of main goes here");
   });
}

Some schedulers have a dispatching loop that must run if they are to work properly, so for the sake of consistency, when using a scheduler, start() must be called within main(). This yields control to the scheduler and will ensure that any spawned threads are executed in an expected manner.

An example Scheduler using kernel threads.

This is an example Scheduler that mirrors the default scheduling behavior of creating one kernel thread per call to spawn. It is fully functional and may be instantiated and used, but is not a necessary part of the default functioning of this module.

An example Scheduler using Fibers.

This is an example scheduler that creates a new Fiber per call to spawn and multiplexes the execution of all fibers within the main thread.

Used to determine whether a Generator is running.

A Generator is a Fiber that periodically returns values of type T to the caller via yield. This is represented as an InputRange.

Sets the Scheduler behavior within the program.

This variable sets the Scheduler behavior within this program. Typically, when setting a Scheduler, scheduler.start() should be called in main. This routine will not return until program execution is complete.