We need a name for a yet vague concept. I am tempted to propose “impetus” which as a physics concept was discredited several hundred years ago. Yet it retains some connotations that I want.

The term ‘process’ is used in older Keykos literature to refer to something in common with the running of a domain and the subsequent running of a domain that the first either calls or returns to.

When one domain calls another to invert a matrix, the second has the same impetus as the first. Analyzing the same situation will, depending on the sort of analysis, assign different impetuses to a given action—it is relative.

Impetus is similar to ‘principal’ which we discredit. It tries to capture the source of the activity—“Why are we doing this?”. It often purports to identify a person. The anthropomorphic notion of principal aspires to a unique absolute answer.

There is a vague feeling that in stack based software the impetus can be identified by something older in the stack. This explains some of the intuitive attraction of stack introspection. The idea of fluid variables is related with one difference; the supplier of the authority explicitly supplies the authority and the consumer explicitly invokes the authority.

All of these concepts suffer from insubstantiality. Several requests may be consolidated and the specific impetus of the combined computation is lost in this transformation. In short the concept seems good only for fuzzy thinking; about things without sharp edges. Some of these notions are useful, however. In Keykos the process (impetus) is time-sliced. The scheduler is not consulted upon gate invocation.

The Unix thread tends to follow an impetus at least in the common thread tutorials.

I don’t know how to characterize code which runs with an identifiable impetus. How does such code relate to code that does not? One characterization is that impetus oriented code limits its attention (state or context) to just one case; multiple instances deal with the other similar cases. This tends to require small domains.

The Unix file system kernel call “read” may in some circumstances return 0 bytes. This is done in those call variants where the file is actually a stream distributed in time and the meaning is “get me what there is now”. The code that gets such a 0 has presumably planned on some other impetus to attend to since the normal next computation indeed depends on the value of that next byte. If the program in question is reading MIDI events from a real time serial port then the concept of impetus perhaps strained beyond utility.