In the first case, the OS will add the caller to a FIFO wait queue
for the requested resource. For example, in the case of fork this
means that the forker will sleep until the VS's process count drops below
the process count limit. The resulting delay may not be acceptable to the
calling application.
Applications that cannot be delayed, should receive an error upon resource
exhaustion. Unfortunately, existing applications may not be able to handle
arbitrary errors. Therefore, we leave it up to the administrator to configure
the error that will be raised if a VS-level resource limit violation is
observed at a particular gate. In this way, only errors that the application
is able to handle will be raised. For example, the administrator may choose
to raise the EAGAIN error for some VS that exceeds its process
count limit upon fork. This behavior is specified at the time
of gate configuration [e.g., servctl(SET_FORK_POLICY, VSIDx,
..., EAGAIN, ...)]. Most server applications are capable of handling
errors that result from resource exhaustion gracefully. They simply record
the error in a server log-file to support system tuning. If neither blocking
nor returning an error is acceptable to the hosted service, the execution
should continue in best-effort mode.