Any model of 'processes' - especially of communications between software components - might be called a ProcessModel. Some examples include the ActorModel, CommunicatingSequentialProcesses, PiCalculus, and FunctionalReactiveProgramming, and even SharedMemory MultiThreading?
- Note that while most programs can be multi-threaded, MultiThreading? cannot be said to be the language's "process model" unless the language explicitly provides support for it (via syntax, semantics, or a standard library). MultiThreading? is one of the least 'safe' and most difficult to comprehend or correctly program models of all, and is popular only because it is simple to implement efficiently - a fine example of failing the KISS principle by going from 'simple' to 'simplistic' where you need to start AddingEpicycles.
Merely having an explicit
ProcessModel does not imply support for
FirstClass processes, but is a precondition for it. The
ProcessModel is required as a basis for mobility, persistence, and runtime construction of new processes.
Not all languages have a ProcessModel, especially those that were largely procedural in design like CeeLanguage or CeePlusPlus, pure functional languages or declarative languages, etc. However, some languages that do have a ProcessModel include ErlangLanguage (which is based on the ActorModel), VeryHighDefinitionLanguage? (FunctionalReactiveProgramming), and various WorkflowLanguage?s.