Deployment

Threading and Concurrency

The class utilizes different underlying technologies on different operating systems. Because of that, the threading model exposed to applications depends in part on the platform class runs on.

NOTE: Even when configured for minimal concurrency, the class always fires events in the context of some worker thread, and not in the thread the class was originally created on. Therefore, applications must be sure to synchronize operations between event handlers and other threads as necessary (including, but not limited to, calls to the class instance, unless a method is explicitly documented as callable within events).

Configuring Event Concurrency

The SerializeEvents property controls whether events relating to different files should be allowed to fire in parallel on several worker threads, or serialized on a single worker thread. By default, this property is set to seOnMultipleThreads, and events for different files are allowed to fire in parallel.

Windows: Generally speaking, the class always enforces per-file event serialization; that is, events relating to the same file are always fired in sequence regardless of the property value. With per-file event serialization already ensured, the most important concurrency-related consideration is whether to enforce multifile event serialization as well, which is what SerializeEvents controls. When SerializeEvents is set to seOnMultipleThreads, the MinWorkerThreadCount, MaxWorkerThreadCount, and WorkerInitialStackSize configuration settings let the application tune the worker thread pool. These settings are ignored when SerializeEvents is set to seOnOneWorkerThread.

Linux: When SerializeEvents is set to seOnMultipleThreads, the class may fire events related to the same file concurrently in several threads. If the application is not prepared for that, it should use seOnOneWorkerThread mode.

macOS: The events always fire on a single worker thread, and the SerializeEvents property has no effect.