Blocking behavior of plug-ins

The correlator system assumes that all functions return in a reasonable amount of time, and do not do potentially blocking operations such as file-system operations or remote calls. For code written in EPL, the correlator can enforce this. For code provided in plug-ins, the correlator cannot enforce this or know whether the method may block. Therefore, by default, the correlator assumes that any plug-in method may block indefinitely. This may cause the correlator to create new operating system threads to service incoming events on other contexts.

If you know that your plug-in does not do anything long-running or potentially blocking, then you may declare the method as "non-blocking" at the point it is registered in the initialize function:

static void initialize(base_plugin_t::method_data_t &md)
{
md.registerMethod<decltype(&MyPlugin::nonBlockingMethod),
&MyPlugin::nonBlockingMethod>("methodName", /*blocking=*/false);
}

For event handlers, this is done with the call to registerEventHandler (see Receiving events).

If you do this, then the correlator assumes that the method will return soon and not spawn additional threads. This can avoid extra overhead of starting and stopping operating system threads.

Caution:

Declaring a method as non-blocking when it actually blocks can cause poor performance or even deadlock the correlator entirely.

If you have a method which is normally non-blocking, but may sometimes block, you can declare it as non-blocking initially and then, when it encounters a condition which is blocking, notify the correlator that this call is blocked to allow the correlator to spawn additional threads.

int64_t get(int64_t key) {
if (local(key)) {
return local(key);
} else {
getCorrelator().pluginMethodBlocking();
return remote(key);
}
}