Since the CBFS Filter classs' Control Events are tied directly to the underlying operations' requests/responses, it's critical their event handlers complete quickly in order to prevent the system from being blocked. To help prevent such blocking, the classs' system drivers can enforce event timeouts.
To enable event timeouts, pass a non-zero value for the Timeout parameter when calling the start_filter method. Passing 0 will disable event timeouts, in which case events may take as long as necessary to execute.
When timeout enforcement is in effect, and an event executes long enough for its timeout to expire, the driver either "releases" the underlying request (passing it onwards unchanged), or cancels it by reporting an error; whichever is most appropriate for the event in question. The tardy event still runs to completion, but any results it returns once finished are ignored since the underlying request has already passed through the filter driver.
If an event handler knows it will require additional time to complete an operation, it can call the reset_timeout method before the current timeout expires to restart its timeout timer.
Applications should always strive to ensure that all event handlers complete quickly, even if request timeouts are disabled. Don't perform time-consuming work within event handlers; offload such work to background threads.
Note that the information discussed above is less relevant for Notification Events which, since they fire asynchronously, cannot block the system. The CBMonitor class, therefore, doesn't expose a Timeout parameter in start_filter, or a method for resetting event timeouts; it operates without event timeout enforcement.