Operations on resource containers

The resource container mechanism includes these operations on containers:

Creating a new container:

A process can create a new resource container at any time (and may have multiple containers available for its use). A default resource container is created for a new process as part of a fork(), and the first thread of the new process is bound to this container. Containers are visible to the application as file descriptors (and so are inherited by a new process after a fork()).

Set a container's parent:

A process can change a container's parent container (or set it to ``no parent'').

Container release:

Processes release their references to containers using close(); once there are no such descriptors, and no threads with resource bindings, to the container, it is destroyed. If the parent P of a container C is destroyed, C's parent is set to ``no parent.''

Sharing containers between processes:

Resource containers can be passed between processes, analogous to the transfer of descriptors between UNIX processes (the sending process retains access to the container). When a process receives a reference to a resource container, it can use this container as a resource context for its own threads. This allows an application to move or share a computation between multiple protection domains, regardless of the container inheritance sequence.

Container attributes:

An application can set and read the attributes of a container. Attributes include scheduling parameters, memory allocation limits, and network QoS values.

Container usage information:

An application can obtain the resource usage information charged to a particular container. This allows a thread that serves multiple containers to timeshare its execution between these containers based on its particular scheduling policy.

These operations control the relationship between containers, threads, sockets, and files:

Binding a thread to a container:

A process can set the resource binding of a thread to a container at any time. Subsequent resource usage by the thread is charged to this resource container. A process can also obtain the current resource binding of a thread.

Reset the scheduler binding:

An application can reset a thread's scheduler binding to include only its current resource binding.

Binding a socket or file to a container:

A process can bind the descriptor for a socket or file to a container; subsequent kernel resource consumption on behalf of this descriptor is charged to the container. A descriptor may be bound to at most one container, but many descriptors may be bound to one container. (Our prototype currently supports binding only sockets, not disk files.)