KModel 
 

Handles and Kernel Resources

Kernel resources allocated to processes are tracked by a list of handles maintained in the process control block. Handles are opaque, meaning that a process cannot manipulate the contents of a handle. Handles are passed to the kernel as arguments to certain system calls. 

Kmodel has a variety of handles, all derived from the same base type. each type of handle has one method in common -- the release() method -- which is invoked to "close", "deallocate", "shutdown" or otherwise deal with returning the resource to the system.

In Unix and Unix-like systems, file descriptors are small integers that act like handles. They are indexes into tables maintained as kernel data structures on behalf of each process. Unix process IDs are like handles -- they are passed to system calls that operate on processes -- but are not unified with file handles.

Win32 uses handles (typedef HANDLE) to describe any kind of resource, although the ostensibly generic CloseHandle() system call does not apply to each kind of handle.

System calls with handles

At the system-call entry to the kernel, arguments are down-level cast to expected reference types. Thus a system call that expects to operate on the vnode for a directory can have a different argument than a system call that expects to work on a regular file.

If an incorrect handle is passed to a system call, a class-cast exception is thrown and the system call fails.

Releasing Handles

When a process terminates, the resources associated with the process are recycled by calling the release() method of each handle.

The same release() method is used to close files or to terminate sub processes. There is a constraint that any handle in the handle list is not released. Alternatively, releasing a handle must coincide with removing the handle from the handle list.

A consequence of this design is that handles cannot be shared, although the resources that they encapsulate can be shared. That is, there is no reference count for a handle. For example, if an open file, as represented by a vnode, is to be shared, a new handle must be created to contain the same vnode and the reference count on the vnode is incremented.