Two concepts are most involved in the scheduler, a concept of modules, and a concept of tasks.

A module is literally a code module, specifically a dynamically loaded library. A task is a thread of execution which could be a thread, another process, or some process on a completely different system.

A module instance can have 0 or more tasks associated with it. A module instance with 0 threads associated with it is an 'on demand' module, invoked only by other modules. A module instance with 1 more more tasks associated with it owns said tasks and when the module is unloaded, the tasks associated with it are terminated. Each module instance must have a unique name.

All tasks must be associated with a module, and and new tasks can be killed or spawned at runtime programatically or via. the command-line interface. In either case the module associated with the task in question will be notified of the task action. Additionally things such as signals and other commands may be sent to a specific task. A task MUST run in the same location as the module it is associated with (ie. same process the module is loaded into).

Tasks may be grouped together for convenience, and the group may act differently depending on which kind of group is selected. Groups are usually used to allow for a message to be passed to one of any number of tasks. Different task groups could be things such as 'FirstAvailable?' (ie. send a message to the first available task), 'RoundRobin?' (rotate between ask tasks) and so on. Each module with associated tasks created an implicit group (which by default is 'FirstAvailable?'). A task may be associated with multiple groups, however there is a cost involved (specifically the requirement of notifying all other groups it is not available when invoked by a different group).

More advanced task grouping methodologies will also be provided such as key-based dispatching, associative dispatching, batch dispatching and so on. Even meta-groups can be provided that will be able to dispatch to one of various groups or provide weighting and flow control or even load balancing. This will probably end up being one of the most powerful features of Mantra.

Mantra should come with a built-in 'generic' module, which has the sole purpose of providing a pool of tasks that will just be used to invoke another module. This will thereby facilitate a generic thread pool that can be used for any purpose.

The ID of a task is entirely numeric and machine generated, however groups and modules must have alphanumeric names (and must start with an alpha character). These names can be changed at runtime, however care should be taken when renaming as it could cause routing failures if this occurs. All module and task group names are case insensitive.