A single application can be broken up into several parts, each one associated with a separate process. This division of labour often makes the program easier to write. As an example consider a screen manager that displays several windows simultaneously and accepts user input from each window. In a sequential processing system, exactly one process is assigned to this application. It would maintain a ``context block'' for each window and ``switch'' among these blocks based on user input. The program for this process would look as follows:
initialize all windows.
loop
wait for user input
determine the window to which it applies
load state of window
service input
save state
end loop
In a multiprocess system, a process could be associated with each window. The state of a window is stored in the variables of its process, and the operating system is responsible for saving and restoring this state and switching among the processes. Moreover, it can support urgent windows (``abort missile launch'') by giving higher priority to processes that manage them. Thus each process is concerned only with servicing input, and not with saving and restoring state.
Perhaps more compelling examples are found in the Web context. Multiprocessing allows a Web browser to execute different animations (shown on a Web page) as separate threads. In the absence of multithreading, the browser would be responsible for context switching between the animations. Even more compelling, multiprocessing allows an HTTP server to execute different pieces of user-supplied code as independent threads or "servlets" written potentially by different people. Thus, multiprocessing allows different people to independently write code executed in a single application (address space) such as a Java virtual machine in the example above.