Failing System Calls

Gates may detect resource limit violations. For example, during the execution of fork it may become apparent that successful call completion would result in a violation the VS's process count limit. The appropriate remedy is application-dependent. One may decide to:

1.

Wait until VS resources become available.

2.

Return an error to the caller indicating resource exhaustion.

3.

Not apply the classification that led to the resource limit violation and silently reclassify the caller as best-effort. If the best-effort VS has exhausted its resource share, there is no other option but to fail the system call.

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, VSID_x, ..., 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.