A process is a container in that it collects context under an authority and consistency, and it is a referent in that it can be the target of scheduling, of signals and communication, and of hierarchies and networks of other processes.

1. A process is an object for a conceptually distinct task.
2. As an object, it is a container (a.k.a. properties) for the context of the task, including the tasks’ memory space, the tasks open files and sockets, and the tasks threads.
3. It is a scheduleable entity (which is entitled to processor cycles), and each of it contained threads are schedulable entities, and can engage in process groups that act together as schedulable entities.
4. It can have relations with other processes as parent-child or process groups.
5. It can have authority through an ownership, and it may transfer that authority; it can request, reserve and releases resources according to that authority. It can engage as a partner in synchronization tasks concerning those resources.
6. It has a virtual memory space which it can populate with a copy of the code which will realize the task, and the data structures calculated during the execution of the task.
7. It serves as the target for communication to the task, and as an address for communications from the task, including signals and messages.

In the new definition a process however does not do anything. It is not running code. That is a thread.

Kernel/User Context

Processes tend to be spoken of as user processes when they run only with user privileges. The kernel is not generally through of as a process, because it can subsume all other contexts, and because it is not scheduled in the say way as other processes. It also has ultimate authority over resources, and hence negotiates for them in entirely different ways than do user processes.

The kernel can adopt at various times various user contexts in order to carry out the requirements of user processes and coordinate and communicate between user processes. Running in kernel context, the kernel is generally considered to have no user context, because it might be reliable which user context is installed.

An interrupt is a forced entry into the kernel to a specific address to service a hardware event. The execution is often run on the same thread as the user thread that was interrupted, but as there can be no assumption which user context was in effect at the time of the interrupt, it is thought of as having no user context. Other times, such as a page fault, the forced entry to the kernel identifies the user context at which the fault occurred, and works with the user context to resolve the resource request.