As we noted in the previous recipe, the operating system does not trust the applications that it allows to run. For this reason, the operating system imposes limits on certain resources. The limitations are imposed to prevent an application from using up all of the available system resources, thus denying other running applications the ability to run. The default limits are usually set much higher than they need to be, which ends up allowing any given application to use up far more resources than it ordinarily should.
Windows 2000 and newer versions provide a mechanism by which applications can self-impose restrictive limits on the resources that it uses. It's a good idea for the programmer to lower the limits to a point where the application can run comfortably, but if something unexpected happens (such as a memory leak or, more to the point, a denial of service attack), the limits cause the application to terminate without bringing down the rest of the system with it.
Operating system resources are difficult for an application to control; the pooling approach used in threads and sockets is difficult to implement when the application does not explicitly allocate and destroy its own resources. System resources, such as memory and CPU time, are best managed using system quotas. The programmer can never be sure that system quotas are enabled when the application is running; therefore, it pays to be defensive and write code that is reasonably aware of system resource management.
The most basic advice will be long familiar from lectures on good programming practice:
Avoid the use of system calls when possible.
Minimize the number of filesystem reads and writes.
Steer away from CPU-intensive or "tight" loops.
Avoid allocating large buffers on the stack.
The ambitious programmer may wish to replace library and operating system resource management subsystems, by such means as writing a memory allocator that enforces a maximum memory usage per thread, or writing a scheduler tied to the system clock which pauses or stops threads and processes after a specified period of time. While these are viable solutions and should be considered for any large-scale project, they greatly increase development time and will likely introduce new bugs into the system.
Instead, you may wish to voluntarily submit to the resource limits enforced by system quotas, thereby in effect "enabling" quotas for the application. This can be done on Windows using job objects . Job objects are created to hold and control processes, imposing limits on them that do not exist on processes outside of the job object. Various restrictions may be imposed upon processes running within a job object, including limiting CPU time, memory usage, and access to the user interface. Here, we are only interested in restricting resource utilization of processes within a job, which will cause any process exceeding any of the imposed limits to be terminated by the operating system.
The first step in using job objects on Windows is to create a job
control object. This is done by calling CreateJobObject(
)
, which requires a set of security attributes
in a SECURITY_ATTRIBUTES structure and a name for
the job object. The job object may be created without a name, in
which case other processes cannot open it, making the job object
private to the process that creates it and its children. If the job
object is created successfully, CreateJobObject( )
returns a handle to the object; otherwise, it returns
NULL, and GetLastError( ) can
be used to determine what caused the failure.
With a handle to a job object in hand, restrictions can be placed on
the processes that run within the job using the
SetInformationJobObject(
)
function, which has the following signature:
BOOL SetInformationJobObject(HANDLE hJob, JOBOBJECTINFOCLASS JobObjectInfoClass,
LPVOID lpJobObjectInfo, DWORD cbJobObjectInfoLength);This function has the following arguments:
hJob
Handle to a job object created with CreateJobObject(
), or opened by name with OpenJobObject(
).
JobObjectInfoClass
Predefined constant value used to specify the type of restriction to
place on the job object. Several constants are defined, but we are
only interested in two of them:
JobObjectBasicLimitInformation and
JobObjectExtendedLimitInformation.
lpJobObjectInfo
Pointer to a filled-in structure that is either a
JOBOBJECT_BASIC_LIMIT_INFORMATION or a
JOBOBJECT_EXTENDED_LIMIT_INFORMATION, depending on
the value specified for JobObjectInfoClass.
cbJobObjectInfoLength
Length of the structure pointed to by
lpJobObjectInfo in bytes.
For the two job object information classes that we are interested in, two data structures are defined. The interesting fields in each structure are:
typedef struct _JOBOBJECT_BASIC_LIMIT_INFORMATION {
LARGE_INTEGER PerProcessUserTimeLimit;
LARGE_INTEGER PerJobUserTimeLimit;
DWORD LimitFlags;
DWORD ActiveProcessLimit;
} JOBOBJECT_BASIC_LIMIT_INFORMATION;
typedef struct _JOBOBJECT_EXTENDED_LIMIT_INFORMATION {
JOBOBJECT_BASIC_LIMIT_INFORMATION BasicLimitInformation;
SIZE_T ProcessMemoryLimit;
SIZE_T JobMemoryLimit;
} JOBOBJECT_EXTENDED_LIMIT_INFORMATION;Note that the structures as presented here are incomplete. Each one
contains several other members that are of no interest to us in this
recipe. In the JOBOBJECT_BASIC_LIMIT_INFORMATION
structure, the LimitFlags member is treated as a
set of flags that control which other structure members are used by
SetInformationJobObject(
)
. The flags that can be set for
LimitFlags that are of interest within the context
of this recipe are:
JOB_OBJECT_LIMIT_ACTIVE_PROCESS
Sets the ActiveProcessLimit member in the
JOBOBJECT_BASIC_LIMIT_INFORMATION structure to the
number of processes to be allowed in the job object.
JOB_OBJECT_LIMIT_JOB_TIME
Sets the PerJobUserTimeLimit member in the
JOBOBJECT_BASIC_LIMIT_INFORMATION structure to the
combined amount of time all processes in the job may spend executing
in user space. In other words, the time each process in the job
spends executing in user space is totaled, and any process that
causes this limit to be exceeded will be terminated. The limit is
specified in units of 100 nanoseconds.
JOB_OBJECT_LIMIT_PROCESS_TIME
Sets the PerProcessUserTimeLimit member in the
JOBOBJECT_BASIC_LIMIT_INFORMATION structure to the
amount of time a process in the job may spend executing in user
space. When a process exceeds the limit, it will be terminated. The
limit is specified in units of 100 nanoseconds.
JOB_OBJECT_LIMIT_JOB_MEMORY
Sets the JobMemoryLimit member in the
JOBOBJECT_EXTENDED_LIMIT_INFORMATION structure to
the maximum amount of memory that all processes in the job may
commit. When the combined total of committed memory of all processes
in the job exceeds this limit, processes will be terminated as they
attempt to commit more memory. The limit is specified in units of
bytes.
JOB_OBJECT_LIMIT_PROCESS_MEMORY
Sets the ProcessMemoryLimit member in the
JOBOBJECT_EXTENDED_LIMIT_INFORMATION structure to
the maximum amount of memory that a process in the job may commit.
When a process attempts to commit memory exceeding this limit, it
will be terminated. The limit is specified in units of bytes.
Once a job object has been created and restrictions have been placed
on it, processes can be assigned to the job by calling
AssignProcessToJobObject(
)
, which has the following signature:
BOOL AssignProcessToJobObject(HANDLE hJob, HANDLE hProcess);
This function has the following arguments:
hJob
Handle to the job object to assign the process.
hProcess
Handle of the process to be assigned.
If the assignment is successful, the
AssignProcessToJobObject( )returns
TRUE; otherwise, it returns
FALSE, and the reason for the failure can be
determined by calling GetLastError( ). Note that
when a process exceeds one of the set limits, it is terminated
immediately without being given the opportunity to perform any
cleanup.